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EXECUTIVE  SUMMARY 


HOS  Is  a  digital  computer  program  designed  to  be  used  In  the 
evaluation  of  complex  crewstatlons .  It  enables  an  analyst  to  dynamically 
simulate  the  activities  of  an  operator  (perception,  anatomy  movement,  decision* 
making,  etc.)  and  the  performance  of  the  hardware  In  response  to  the  operator's 
actions.  Like  a  real  operator,  the  HOS  operator  must  be  taught  how  to  use  a 
system  by  supplying  It  with  a  description  of  how  the  equipment  operates,  the 
circumstances  under  which  the  equipment  Is  used,  and  tactical  strategies  to 
be  pursued  In  order  to  accomplish  specific  goals.  The  operator  can  then  be 
placed  In  a  specific  tactical  environment  and  will  respond  to  the  dynamics  of 
the  situation  just  as  an  actual  operator  would  under  similar  circumstances. 
Models  of  human  performance  In  HOS  predict  how  long  each  specific  operator 
activity  will  take.  The  HOS  operator  will  adapt  his  behavior  to  the  dynamics 
of  the  tactical  situation  In  accordance  with  the  rules  by  which  he  has  been 
trained.  By  controlling  the  tactical  situations,  the  analyst  can  use  HOS  to 
obtain  data  on  human  and  system  performance  In  hypothetical  tactical  situations* 
data  that  heretofore  could  only  be  obtained  at  too  late  a  stage  In  the  system 
development  to  have  a  significant  Impact  on  the  system  design.  HOS  enables 
different  system  configurations  and  operator  strategies  to  be  tested  and 
studied  without  having  to  build  hardware  or  train  operators,  or  run  actual 
experiments  or  exercises.^ 

Although  HOS  was  designed  for  the  human  engineering  comnunlty  as  a 
design  and  evaluation  tool.  Its  potential  usefulness  extends  well  beyond  the 
classical  scope  of  human  engineering  design  and  evaluation  probelms.  This 
presentation  will  focus  on  the  role  that  HOS  can  play  In  the  system  design 
process  and  on  specific  details  of  the  HOS  operator  models.  More  detailed 
discussions  on  how  to  use  HOS  are  presented  In  the  HOS  Study  Guide  (Strleb, 
Glenn,  and  Wherry,  1978).  -  . — 
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1 .  THE  ROLE  OF  OPERATOR  MOOELS  IN 
SYSTEM  DESIGN  ANO  EVALUATION 


1.1  HUMAN  ENGINEERING  ANO  THE  SYSTEM  DESIGN  PROCESS 

In  order  to  place  the  role  of  HOS  In  the  proper  perspective.  It  is 
useful  to  look  at  the  system  design  process,  at  the  role  that  human  engineers 
play  In  that  process  and  some  of  the  tools  and  models  that  have  been  developed 
to  assist  in  this  process,  particularly  with  respect  to  human  performance 
evaluation. 

One  way  of  looking  at  the  role  of  the  human  engineer  is  in  terms 
of  the  types  of  analyses  required  to  support  each  stage  of  the  system  acquisi¬ 
tion  process.  Program  development  can  be  divided  into  four  major  phases,  based 
on  major  decision  points  In  the  weapons  system  acquisition  process: 

(1)  Program  Initiation 

(2)  Demonstration  and  Validation 

(3)  Full  Scale  Engineering  Development 

(4)  Production  and  Deployment 

Within  each  of  these  phases,  there  are  a  variety  of  types  of  analyses 
required  by  or  performed  by  the  human  engineer.  During  the  program  Initiation 
stage,  for  example,  some  of  the  types  of  analyses  are: 

•  Identification  of  Operational  Conditions 

•  Requirements  Analysis 

•  Preliminary  Function  Allocation 
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a  Preliminary  Manning  Analysis 

•  Preliminary  Task  Analysis 

e  Operational  Sequence  Analysis 

During  the  concept  refinement  and  prototype  development  phase,  some 
of  the  additional  types  of  analyses  required  are: 

•  Crewstatlon  Workspace  Layouts 

•  Control /Display  Design  Requirements 

•  Man-Machine  Tradeoffs 

e  Maintenance/Training  Objectives  and  Requirements 

•  Personnel  Selection  Requirements 

In  the  full  scale  engineering  development  stage,  the  required 
analyses  are  associated  with  developing  training  programs  and  operational  pro¬ 
cedures.  And,  finally,  in  the  production  and  deployment  stages,  analyses 
Include  the  development  of  solutions  to  operational  problems,  and  the  analysis, 
by  similar  techniques,  of  retrofits  and  upgrades. 

Related  to  these  are  the  human  factors  program  requirements  defined 
In  MIL-H-46855.  These  Include: 

•  Defining  and  allocating  system  functions. 

•  Information  flow  and  processing  analysis. 

•  Estimates  of  potential  operator/malntainer  processing 
capabilities. 

a  Equipment  Identification. 

a  Task  analysis. 

e  Analysis  of  critical  tasks. 

a  Loading  analysis. 
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•  Preliminary  and  detailed  system  and  subsystem  design, 
e  Studies,  experiments,  laboratory  tests, 
e  Mockups  and  models, 

e  Dynamic  simulation, 

e  Design  drawings, 

e  Workspace  environment, 

e  Test  and  evaluation. 

Another  way  of  viewing  the  role  of  the  hunan  factors  engineer  is  in 
terms  of  the  specific  problems  with  which  he  Is  faced.  In  general,  human 
factors  system  design  efforts  can  be  subdivided  into  six  substantive  areas: 

(1)  Tasks  and  Functions  to  be  Allocated  to  Humans 

(a)  The  type  of  functions  that  should  be  allocated  to  humans. 

(b)  The  degree  to  which  various  functions  must  be  automated 
to  ensure  that  system  operators  will  not  be  overloaded. 

(c)  The  specific  functions  taht  should  be  allocated  to  each 
equipment  operator, 

(2)  Human  Information  Processing  Procedures 

(a)  The  relative  priority  of  various  assigned  tasks. 

(b)  The  specific  steps  that  the  human  Is  expected  to  perform 
In  each  assigned  task. 

(c)  Various  kinds  of  Information  processing  performed  by  each 
human  element. 

(d)  The  expected  speed  and  accuracy  of  the  operator's  per¬ 
formance  on  each  task. 

(3)  Panel  and  Console  Design 

(a)  Required  types  and  sizes  of  displays  and  controls. 

(b)  Their  locations  and  arrangement  on  panels  and  consoles. 

(c)  Panel  markings  and  arrangement  within  each  crewstatlon. 
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(a)  Equipment  handles,  fasteners,  connectors,  and  access 
points  for  test  and  Inspection. 

(b)  Special  support  equipment  to  aid  the  loading,  unloading, 
transporting,  etc.,  of  equipment. 

(c)  Special  tools  and  equipment  required  for  fault  detection. 
Isolation,  and  correction. 

(5)  Environmental  Control,  Ingress  and  Egress 

(a)  Supports  and  restraints  required  for  each  crew  member. 

(b)  Personal  equipment  and  clothing. 

(c)  Normal  and  emergency  Ingress  and  egress  equipment. 

(d)  Crew  station  lighting,  air  conditioning,  noise  suppression, 
and  other  habitability  considerations. 

(6)  Training  Manuals  and  Job  Aids 

The  Information  and  procedures  that  the  human  would  have  dif¬ 
ficulty  memorizing  and  that  are  therefore  stored  as  reference 

material . 


It  would  be  useful  to  many  of  the  above  types  of  design  activities 
to  be  able  to  actually  "place"  actual  operators  In  a  proposed  system  to  . 
provide  a  realistic  assessment  of  how  well  the  system  Is  suited  to  human 
capabilities  and  limitations.  Unfortunately,  It  Is  usually  not  until  late  In 
the  full  scale  engineering  development  stage  that  such  assessments  can  be 
made.  Before  then,  analyses  have  to  be  based  on  models,  mockups,  and  "educated 
guesses." 

Therefore,  a  variety  of  tools  have  been  developed  to  assist  In  the 
system  design  and  evaluation  process.  To  better  understand  how  the  HOS  model 
relates  to  some  of  these  other  tools,  It  Is  useful  to  review  the  role  of 
models  and  some  of  the  critical  Issues  associated  with  model  development. 


1.2  THE  ROLE  OF  MODELS 

Models  are  developed  for  any  of  several  reasons: 

e  Because  phenomena  that  we  wish  to  study,  such  as  human  per* 
formance,  are  too  complex  to  be  dealt  with  directly. 

e  Because  systems  that  we  wish  to  study  have  not  been  developed 
to  a  sufficient  state  that  they  can  be  studied  directly. 

e  Because  conditions  that  we  wish  to  study  cannot  be  created 
except  at  great  expense  or  at  the  risk  of  life. 

Models  attempt  to  reduce  the  complexities  of  actual  situations  to 
simpler  forms  that  are  more  amenable  to  study  and  analysis. 

Because  of  the  complexity  of  human  performance,  models  of  human 
performance  may  exist  any  any  one  of  a  number  of  levels  of  detail.  At  certain 
stages  of  system  development,  a  model  that  describes  human  performance  in 
terms  of  the  gross  tasks  that  the  operator  must  perform  might  suffice;  in 
later  stages,  it  may  be  necessary  for  these  tasks  to  be  broken  down  into 
descriptions  of  how  the  operator  interfaces  with  his  displays  and  controls  and, 
still  further,  into  the  actual  eye  and  hand  movements  that  he  makes  and  the 
cognitive  processes  that  govern  his  selection  of  actions.  For  still  other 
purposes,  it  may  be  important  for  these  processes  to  be  broken  down  into  the 
subprocesses  that  control  movement  and  brain  functioning  and  ultimately  into 
biochemical  processes.  Therefore,  when  attempting  to  choose  a  model  of  human 
performance  for  a  particular  application,  the  modeler  must: 

(1)  determine  the  point  at  which  he  no  longer  cares  to  attempt 
to  describe  in  any  more  detail  the  actual  subprocesses,  and 

(2)  Ensure  that  the  subprocesses  that  are  described  are  con¬ 
catenated  in  such  a  way  that  they  accurately  reflect  the 
behavior  of  the  system  being  modeled. 

The  first  point  addresses  the  level  of  detail  attained  by  any  par¬ 
ticular  model  —  a  critical  issue  which  must  be  carefully  assessed  when 
attempting  to  select  the  appropriate  model  for  any  particular  problem.  What 
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Information  the  model  can  be  expected  to  supply  and,  conversely,  the  choice 
of  a  level  of  detail,  are  determined  by  the  problems  that  the  model  Is  designed 
to  address. 


After  reviewing  the  human  performance  literature.  It  becomes  apparent 
that  there  are  vast  differences  in  the  levels  of  detail  addressed  by  the 
various  models  that  have  been  developed  as  well  as  the  problems  they  are 
designed  to  address.  To  place  HOS  In  perspective  with  respect  to  these  other 
operator  models.  It  Is  useful  to  characterize  models  as  either: 

•  Task  Analytic  Models 

•  Control  Theory  Models 

e  Ml cro-process  Model s 

Each  type  of  model  attempts  to  cope  with  both  the  complexity  and 
variability  of  human  performance  In  different  ways.  The  characteristics  of 
these  models  are  discussed  below. 

1.3  TASK  ANALYTIC  MODELS 

Task  analytic  models  are  those  In  which  the  tasks  assigned  to  the 
operator(s)  are  described,  either  Implicitly  or  explicitly,  as  a  network  In 
which  the  timing  and  sequencing  through  each  mission  stage  (network  "node") 
are  structured  by  the  analyst.  In  these  models,  it  Is  usually  the  user's 
responsibility  to  predetermine  all  the  characteristics  of  each  node.  Including 
times  (or  conditions)  under  which  the  node  will  be  executed,  nominal  execution 
times,  probabilities  of  successful  completion,  transition  probabilities  to 
other  nodes,  etc.  Task  analytic  models  can  be  of  highly  varying  degrees  of 
complexity,  sophistication,  and  detail.  For  example,  the  methodology  known 
as  task  analysis  is  a  task  analytic  model  with  relatively  few  dynamic  features  - 
it  can  be  used  to  produce  a  nominal  timeline  for  estimating  system  performance, 
but  is  only  minimally  responsive  to  the  possible  variations  that  can  occur  In 
actual  operations  that  would  impact  system  performance.  Other  analytic 
models  (e.g.,  Siegel -Wolf  and  SAINT)  are  stochastic  (Monte-Carlo)  models 
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In  which  the  network  Is  executed  many  times  with  Input  conditions  and,  possibly, 
nodal  characteristics  that  vary  according  to  distributions  supplied  by  the 
modeler,  resulting  In  outputs  that  predict  sunmary  performance  measures  such 
as  overall  mission  success.  Other  models  (e.g.,  the  CAFES,  WAM,  and  FAM 
models)  perform  primarily  bookkeeping  functions  or  have  built-in  decision 
algorithms  that  modify  the  task  network  to  optimize  performance. 

In  general,  it  Is  the  modeler's  responsibility  when  using  these 
models  to  fully  describe  the  task  network  and  possible  interactions.  The 
accuracy  of  such  inputs  may  be  either  good  or  bad,  depending  on  the  modeler's 
apriori  knowledge  and  experience  with  the  situation  being  modeled. 

Task  analytic  models  are  human  performance  models  in  that  they  attempt 
to  describe,  in  some  sense,  the  performance  achieved  by  one  or  more  humans  in 
combination  with  a  system.  However,  they  do  not  contain  a  model  of  the  human, 
per  se.  The  success  of  the  model  is,  in  fact,  dependent  on  how  successful 
the  modeler  is  at  describing  the  network  and  in  assigning  times,  condi¬ 
tions,  and  probabilities jthat  accurately  reflect  the  situation  being  simu¬ 
lated. 

1.4  CONTROL  THEORY 

In  (manual  and  optimal)  control  theory  models,  the  interactions 
between  the  operator  and  the  system  are  represented  by  servo-control  models. 
Unlike  the  task  analytic  models,  control  theory  models  da  have  an  explicit 
(and  general)  model  of  human  performance  —  namely  that  an  operator  behaves  in 
such  a  way  that  errors  are  minimized  within  fixed  performance  constraints. 

Control  theory  models  have  typically  been  used  to  examine  human 
performance  in  situations  in  which  a  single  display/control  relationship  and 
the  operator's  response  under  a  variety  of  environmental  conditions  are  critical 
Thus,  manual  and  optimal  control  modelers  have  devoted  extensive  study  to,  for 
example,  pilot  landing  performance  under  a  variety  of  external  (e.g.,  buffet- 
ting)  conditions. 


1.5  MICRO-PROCESS  MODELS 

Micro-process  models  are  detailed  representations  of  the  operator 
In  terms  of  the  physical,  psychological  and  phsyslologlcal  processes  that  are 
Involved  in  carrying  out  a  task.  In  order  to  use  such  a  model ,  the  analyst 
must  describe  the  specific  tasks  that  the  operator  must  perform.  The  model 
then  generates  performance  predictions  for  the  tasks  based  upon  the  modeled 
processes.  Note  that  there  are  actually  two  models  involved  —  the  description 
of  the  tasks  to  be  performed  is  a  model  (just  as  It  was  In  the  task  analytic 
models)  and  the  way  in  which  the  micro-process  model  translates  those  tasks 
Into  activities  Is  also  a  model. 

1.6  A  COMPARISON  OF  MICRO-PROCESS.  TASK  ANALYTIC.  AND  CONTROL  THEORY  MOPaS 
To  Illustrate  the  differences  between  the  various  types  of  models, 

suppose  that  we  are  Interested  In  modeling  an  operator's  tracking  behavior, 
perhaps  as  part  of  a  larger  model  of  pilot  performance. 

The  simplest  task  analytic  description  for  this  situation  would 
be  the  statement: 

PILOT  TRACKS  TARGET 

with  a  time  charge  assessed  for  that  activity.  A  more  complex  task  analytic 
model  might  subdivide  the  macro-level  activity  "tracks"  Into  more  micro-level 
activities  —  for  example: 

PILOT  LOOKS  AT  TARGET 

PILOT  MANIPULATES  CONTROL 

and  again  times  would  be  assessed  for  each  activity.  A  dynamic  (stochastic) 
task  analytic  model  might  Include  logic  that  described  the  probability  that 
the  pilot  would  need  to  perform  a  corrective  activity  and/or  probabilities 
that  the  operator  would  have  to  Iterate  through  a  control  loop. 
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A  control  theory  model  of  the  same  problem  would  typically  concern 
Itself  primarily  with  the  dynamics  of  the  control  loop.  It  would  include  a 
detailed  mathematical  description  of  the  target's  behavior  and  the  pilot's 
response  to  that  stimulus  and  mathematically  model  features  such  as  the  operator 
and  the  system  response  lags,  motor  noise,  etc. 

A  micro-process  model,  on  the  other  hand,  would  take  the  activities 
described  by  the  task  analytic  description  of  the  operator's  tasks  and  the 
dynamic  behavior  of  the  system,  as  described  by  the  control  theory  models, 
and  combine  them  to  model  the  behavior  of  the  operator  In  response  to  system 
stimuli.  For  example,  a  micro-process  model  might  break  down  the  statement 

PILOT  LOOKS  AT  TARGET 

into  a  set  of  activities  shown  in  Figure  1. 

There  are  significant  differences  between  the  task  analytic  model 
and  the  micro-process  model  for  these  tasks.  For  example,  unlike  the  task 
analytic  model  which  would  have  assessed  a  time  charge  whether  or  not  the 
pilot  was  already  looking  at  the  target,  the  micro-process  model  would  not. 

A  micro-process  model  retains  complete  knowledge  both  of  what  the  operator  is 
doing  and  what  the  target  Is  doing  at  any  instant,  thereby  enabling  unnecessary 
time  charges  to  be  eliminated  and  accurate  time  charges  to  be  assigned  only 
for  operator  activities  that  actually  are  needed.  Moreover,  the  time  charges 
assessed  can  be  based  on  actual  experimental  data  rather  than  on  subjective 
estimates  by  an  analyst,  since  the  activities  are  at  a  level  for  which  experi¬ 
mental  data  is  available. 

1.7  DETERMINISTIC  VS  STOCHASTIC  MODELS 

Micro-process  models  are  basically  extensions  of  the  task  analytic 
approach.  They  reduce  task  activities  to  the  level  of  elementary  human  pro¬ 
cesses  —  anatomy  movement.  Information  absorption,  etc.,  —  and  combine  operator 
activities  with  the  dynamics  of  the  system  and  the  external  world.  Thus,  some 


Figure  1.  A  Micro-procas  Tracking  Modal 
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of  the  features  of  micro-process  models  could  be  achieved  In  a  dynamic  task 
analytic  model  in  which  each  task  analytic  node  corresponded  to  a  micro-process. 
However,  there  is  a  fundamental  difference  between  the  way  in  which  micro¬ 
process  models  and  both  task-analytic  and  control  theory  models  view  human 
performance.  In  particular,  micro-process  models  make  the  fundamental  assump¬ 
tion  that  an  operator's  behavior  is  explainable  and  not  random  —  that  an 
operator's  actions  and  the  times  that  those  actions  will  take  are  determined 
fully  by  the  state  of  the  system  and  the  operator's  goals  at  any  particular 
point  of  time.  Thus,  micro-process  models  are  basically  deterministic  models 
(although  individual  micro-processes  may  contain  random  components),  rather 
than  stochastic  models.  However,  because  of  the  way  in  which  various 
micro-models  interact,  the  output  from  a  micro-process  model  will  exhibit 
variability,  making  it  seem,  in  some  cases,  indistinguishable  from  stochastic 
output. 

1.8  THE  MAIL  SORTING  PROBLEM 

As  a  further  illustration  of  the  difference  between  the  micro¬ 
process  and  the  task  analytic  approaches,  let  us  compare  the  task  analytic 
version  of  a  problem  with  the  micro-process  version  of  the  same  problem.  The 
sample  problem  that  will  will  use  is  the  design  of  a  mail  sorting  console  for 
the  Post  Office.  In  designing  such  an  operator  station,  a  variety  of  design 
decisions  must  be  made  —  characteristics  and  locations  of  individual  keys, 
pacing  of  the  system,  etc.  Assume  that  it  has  been  decided  that  the  machine 
will  be  self-paced  —  In  order  to  have  the  next  letter  presented,  the  operator 
must  depress  a  feed  key.  Once  a  letter  is  at  the  read  station,  the  operator 
must  make  a  decision  as  to  whether  the  first  three  digits  of  the  letter 
Indicates  a  destination  within  the  local  area  or  not.  If  the  area  code  is 
local,  the  operator  must  depress  a  local  key  and  then  enter  the  last  two 
digits  of  the  zip  code  corresponding  to  the  city  zone.  If  the  area  code  is 
not  local,  then  the  operator  must  enter  the  three  digits  corresponding  to  the 
area  code. 


A  task  analytic  network  model  for  this  system  is  shown  in  Figure  2. 
Note  that  the  analyst  is  required  to  supply  means  and  standard  deviations  at 
each  node  In  the  network  for  the  times  that  the  activities  represented  by  the 
nodes  will  take.  In  addition,  the  analyst  must  supply  transition  probabilities 
at  each  node  where  a  decision  is  made.  However,  even  If  the  analyst  had  values 
for  these  numbers  for  a  particular  situation  based  on  experimental  data,  the 
numbers  would  most  likely  be  totally  Inappropriate  for  a  new  system  that  was 
In  any  significant  sense  different  from  the  one  from  which  the  numbers  came. 
Thus,  In  many  respects.  It  would  be  virtually  impossible  to  use  the  task 
analytic  network  with  any  confidence  to  resolve  the  Issue  of  Interest  —  the 
efficacy  of  alternative  designs. 

The  flowchart  for  a  micro-process  model  of  the  same  situation 
would  be  almost  identical.  But  with  a  micro-process  model,  the  analyst 
would  not  have  to  supply  the  times  and  transition  probabilities  based  on  the 
specific  task  damands,  the  characteristics  of  the  operator  and  of  the  system. 
For  example,  when  the  task  ’’DEPRESS  FEED  KEY"  was  to  be  executed,  a  micro¬ 
process  model  would  determine  the  time  required  to  move  the  operator's  hand 
from  wherever  it  was  at  the  time  the  action  was  required  to  the  control  and 
the  time  for  the  control  manipulation,  based  on  the  characteristics  of  the 
control.  At  the  decision  point  "IS  AREA  COOE  LOCAL,"  a  micro-process  model 
would  cause  the  operator  to  "look"  at  the  first  three  digits  of  the  zip  code, 
determine  their  value,  and  make  the  decision  as  to  whether  It  was  local  or  not. 

The  primary  advantage  of  the  micro-process  model ,  besides  the 
reduction  In  the  number  of  input  data  values  required.  Is  that  the  micro¬ 
process  model  enables  us  to  ask  questions  that  could  not  be  asked  of  the  task 
analytic  model.  For  example,  what  would  be  the  effect  of  changing  the  control 
locations?  Of  making  the  system  forced  paced  rather  than  self-paced?  Of 
changing  the  control  characteristics? 
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BEGIN 


Figure  2.  A  Talk  Analytic  Modal 
for  tha  Mail  Sorting  Problam 


The  HOS  model  Is  an  example  of  a  micro-process  model  and  Is  the 
only  micro-process  model  that  has  been  developed  to  such  an  extent  that  It 
can  be  applied  to  complex  system  design  problems.  The  following  sections 
will  describe  the  HOS  model  In  more  detail. 
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2.  THE  HOS  MOOEl 


2.1  CHARACTERISTICS  OF  THE  HOS  OPERATOR 

The  HOS  operator  is  assumed  to  be  a  highly  motivated,  well -trained, 
average  operator.  In  addition,  the  HOS  model  assumes  that  the  performance  of 
the  operator  and  the  rules  that  an  operator  should  use  In  operating  a  system 
can  be  explicitly  described  as  a  series  of  procedures  and  statements  that 
describe  the  operator's  activities  and  the  decisions  that  the  operator  must 
make.  Other  characteristics  of  the  HOS  operator  are: 

(1)  The  position  of  the  operator  relative  to  the  displays  and 
controls  in  the  crewstatlon  must  be  fixed  —  i.e.,  the  operator 
is  stationary. 

(2)  The  operator  can  only  process  one  task  statement  at  a  time. 
However,  once  a  statement  has  been  processed,  the  operator  can 
begin  work  on  the  next  statement,  even  though  actions  initiated 
in  the  preceding  statement  may  still  be  continuing.  Thus,  the 
HOS  operator  can  be  performing  several  actions  simultaneously  — 
e.g.,  reading  a  display  and  manipulating  a  control  simultaneously, 
manipulating  two  controls,  one  with  each  hand,  etc. 

(3)  The  operator  is  a  multi -processor  in  the  sense  that  several 
procedures  can  be  "active"  simultaneously,  although  only  one 
can  be  worked  on  at  any  given  time. 

(4)  Operator  performance  variability  in  HOS  is  assumed  to  be  the 
result  of  differences  in  performance  capabilities  coupled  with 
differences  In  operator  strategies.  Differences  in  performance 
capabilities  are  represented  by  parametric  differences  in  the 
functional  relationships  In  the  micro-models.  Differences  in 
operator  strategies  are  representable  as  either  different 
decision  rules  In  the  operator  procedures  or  as  differing 
prioritizations  of  the  operator  procedures. 

(5)  The  HOS  operator  carries  out  instructions  without  omitting  a 
step,  making  an  Incorrect  decision  (based  on  the  decision 
rules  specified  in  the  instruction  set)  or  Incorrectly  carrying 
out  an  instruction. 
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OPERATOR  ERROR 

The  last  point  above  refers  to  one  of  the  most  controversial  Issues 
associated  with  HOS  —  Its  model  of  operator  error.  To  understand  this  model. 

It  Is  Important  to  remember  that  the  primary  objective  for  which  HOS  was 
developed  was  the  evaluation  of  the  nominal  performance  of  a  system  by  a 
well-trained,  average  operator.  By  definition,  a  well -trained  operator  Is 
one  who  carries  out  Instructions  "by  the  book,"  without  omitting  a  step,  making 
an  Incorrect  decision  (based  on  the  decision  rules  specified  In  the  Instruction 
set),  or  Incorrectly  carrying  out  an  Instructions.  However,  this  definition 
does  not  preclude  all  sources  of  operator  error.  For  HOS,  the  significant 
sources  of  operator  error  are: 

(1)  Requiring  the  operator  to  perform  more  activities  In  a  given 
period  of  time  than  possible  (because  of  human  and/or  equipment 
limitations),  thereby  causing  the  operator  to  "fall  behind"  in 
the  mission. 

(2)  Giving  the  operator  an  Incorrect  set  of  decision  rules  and/or 
operating  Instructions,  thereby  causing  tactical  and/or 
operational  errors. 

(3)  Giving  the  operator  poor  displays  and/or  controls  that  do  not 
permit  Information  to  be  read  or  controlled  with  sufficient 
accuracy  to  permit  proper  operation  of  the  system,  causing 
errors  to  occur  In  carrying  out  subsequent  (or  concurrent) 
operations  and/or  requiring  the  operator  to  invest  more  time, 
once  again  causing  the  operator  to  fall  behind  In  the  mission. 

These  types  of  errors  result  In  operator  performance  errors,  but 
are  really  failures  In  the  design  of  the  system  —  flaws  which  the  human 
factors  engineer  must  address  In  proposing  design  modifications.  They  are 
problems  created  when  system  designers  fall  to  take  Into  account  human  per¬ 
formance  limitations.  Clearly,  they  are  not  errors  of  the  same  sort  as  when 
an  operator  inadvertently  pushes  a  wrong  button  —  such  errors  are  either 
random  and  of  low  frequency  (in  which  case  it  Is  unfair  to  use  them  to  evaluate 
the  nominal  performance  of  the  system)  or  caused  by  working  the  operator 
beyond  capacity.  They  are,  however,  the  types  of  errors  that  must  be  engineered 
out  of  the  system. 


2.3  THE  HOPROC  LANGUAGE 

In  order  to  be  able  to  describe  the  operator  activities  In  a  task 
analytic  or  a  micro-process  model.  It  Is  necessary  to  have  a  formal  task 
language.  One  task  analytic  model,  the  System  Analysis  of  an  Integrated 
Network  of  Tasks  (SAINT)  model,  uses  a  graphical  notatlonal  system  (Figure  3) 
to  represent  the  task  network.  The  SAINT  notatlonal  system  can  be  readily 
converted  to  numeric  strings  that  describe  each  task  and  input  to  the  SAINT 
program. 


HOS  uses  an  Engl ish/FORTRAN-1 ike  language  —  the  Human  Operator 
Procedures  (HOPROC)  language  —  for  the  same  purpose.  However,  HOPROC  state¬ 
ments  do  not  need  to  be  converted  into  numeric  entries  ~  HOS  interprets  HOPROC 
statements  directly,  just  as  an  actual  system  operator  can  interpret  English 
Instructions. 

The  HOPROC  language  Is  divided  Into  three  major  sections  —  the 
title  declarations  section,  the  hardware  section,  and  the  operator  section. 

In  the  title  declarations  section  (Figure  4),  the  analyst  identifies  the  names 
of  all  the  displays  and  controls  in  the  crewstatlon  and  their  generic  charac¬ 
teristics  —  whether  they  are  discrete  or  continuous,  their  settings  (if  any) 
and  their  associated  scale  factors  (If  any). 

The  operator  section  is  divided  Into  a  set  of  operator  procedures 
and  a  set  of  operator  functions.  The  operator  procedures  are  English-like 
statements  that  describe  the  operator's  tasks.  The  operator  functions  are 
FORTRAN-1  Ike  descriptions  of  the  mental  calculations  that  the  operator  has 
to  perform  to  carry  out  those  tasks. 

Similarly,  the  hardware  section  Is  divided  Into  a  set  of  hardware 
procedures  and  hardware  functions.  The  hardware  procedures  describe  the 
hardware  changes  that  occur  as  the  result  of  the  actions  of  the  operator,  as 
well  as  Independent  events,  such  as  the  movement  of  external  targets,  changes 
In  the  environment,  etc.  Like  the  operator  procedures,  the  hardware  procedures 
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Portion  of  a  SAINT  Task 


SYSTEM 


SETTING  SECTION 
OSTATE  SECTION 

argument  section 

AMOUNT 

COUNT 


NAIL  SORTING  CASE  A 


NUNBER-OF-DI6ITS 
DISPLAY  SECTION 
ZIP-CODE 
CONTROL  SECTION 
LOCAL -NET 
FEED-KEY 

KEYSET  1,10  NUMBER 


MOMENTARY 

MOMENTARY 

MOMENTARY 


Figure  4.  The  Title  Delcarations  for  the  Mall  Sorting  Problem 
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are  written  as  English-like  statements.  The  hardware  functions,  like  the 
operator  functions,  are  written  as  FORTRAN-! Ike  statements  and  describe  the 
mathematical  calculations  required  to  support  the  hardware  procedures. 


2.4  ACCESSING  THE  MICRO-MOOELS 

HOS  Interprets  each  HOPROC  statement  and  converts  it  into  a  series 
of  operator  actions.  Every  action  that  the  HOS  operator  performs  is  a  com¬ 
bination  of  one  or  more  of  seven  primitive  functions.  The  seven  primitive 
functions  are: 

(1)  Obtaining  information; 

(2)  Remembering  information; 

(3)  Performing  a  mental  computation; 

(4)  Making  a  decision; 

(5)  Moving  a  body  part; 

(6)  Performing  a  control  manipulation;  and 

(7)  Relaxing. 

Although  an  analyst  can  write  HOPROC  statements  that  will  force  the  operator 
to  perform  a  particular  primitive  at  a  particular  point  in  a  sequence  of 
actions,  generally,  the  analyst  will  let  HOS  determine  the  primitives  required 
to  accomplish  a  particular  task  for  itself. 

The  primitive  functions  are  often  either  Imbedded  In,  or  contain 
within  themselves,  human  performance  models.  For  example,  when  a  situation 
arises  in  which  the  operator  must  move  his  hand  to  a  particular  device,  there 
Is  logic  that  determines  which  hand  he  will  use.  Similarly,  when  the  operator 
attempts  to  recall  some  item  of  information,  there  Is  a  reoall  model  that  Is 
automatically  assessed  by  the  program  that  simulates  the  operator's  short¬ 
term  memory  processes. 
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The  primitive  function  calls  that  result  from  two  HOPROC  statements  — 
the  READ  statement  and  the  ALTER  statement  —  are  shown  in  Figures  5  and  6. 

The  READ  statement  (Figure  5)  has  the  simpler  sequence  of  calls.  When  the 
READ  statement  is  encountered,  the  anatomy  movement  micro-model  is  called. 

Based  on  the  type  of  display  or  control  to  read,  the  anatomy  mover  determines 
which  body  part  is  required  in  order  to  absorb  Information  from  the  device. 

It  then  computes  the  amount  of  time  required  to  bring  that  body  part  into 
contact  with  the  device.  The  information  absorption  micro-model  is  then 
called  to  determine  how  long  it  will  take  to  read  the  value  of  the  display  or 
control . 


The  ALTER  statement  (Figure  6)  has  a  somewhat  more  complicated 
flow.  When  the  statement  is  encountered,  HOS  first  determines  whether  the 
current  value  of  the  device  is  the  same  as  the  value  to  which  the  device  Is  to 
be  changed.  It  does  this  by  calling  the  recall  micro-model  to  determine 
whether  the  operator  can  recall  the  value  of  the  display  or  control.  If  the 
value  cannot  be  recalled,  the  anatomy  movement  and  the  Information  absorption 
micro-models  are  called  to  obtain  the  device  value,  as  with  the  REAO  statement. 
Once  the  value  has  been  obtained,  whether  by  recall  or  through  the  information 
absorption  model,  the  current  value  and  the  desired  value  are  compared.  If 
they  differ,  then  the  necessary  actions  are  taken  to  correct  the  device  value. 
In  the  case  of  controls,  the  necessary  actions  require  a  single  call  to  the 
anatomy  mover  and  to  the  control  manipulation  micro-model.  In  the  case  of 
displays,  however,  a  series  of  control  manipulations  may  be  required.  These 
manipulations  must  be  described  in  a  special  type  of  procedure,  called  an 
adjust  procedure,  associated  with  the  display.  HOS  places  the  adjust  pro¬ 
cedure  on  a  list  of  active  procedures,  to  be  executed  either  when  the  operator 
has  time  or  when  another  procedural  statement  requires  the  completetion  of  the 
adjustment. 
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Figure  5.  Procreiing  th«  READ  Swnmnt 
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The  other  micro-models  may  be  accessed  as  a  consequence  of  other 
types  of  procedural  statements  or  on  an  as-needed  basis.  For  example.  If 
an  ALTER  statement  requires  a  mental  computation  to  determine  the  desired 
value  for  a  device,  the  mental  computation  micro-model  can  be  accessed  by 
Including  the  name  of  the  computation  In  the  ALTER  statement  Itself. 
Alternatively,  there  Is  a  HOPROC  statement  (COMPUTE)  that  Is  similar  to  REAO 
except  that  It  Invokes  the  mental  computation  micro-model  rather  than  the 
Information  absorption  micro-model . 

One  characteristic  of  the  mental  computation  micro-model  Is  that 
It  may  require  calls  to  the  other  micro-models  In  order  to  carry  out  the 
necessary  calculations.  For  example,  a  mental  calculation  may  require  the 
value  of  a  displayed  quantity.  The  mental  calculation  micro-model  will  auto¬ 
matically  Initiate  calls  to  the  other  micro-models  —  recall,  anatomy  move¬ 
ment,  Information  absorption,  etc.  —  as  necessary  In  order  to  obtain  the 
required  values. 

The  decision  making  micro-model  Is  accessed  whenever  a  task  statement 
requires  a  decision  or  whenever  the  operator  must  make  a  decision  about 
what  procedure  to  work  on  next.  The  statement  decisions  are  expressed  as 
IF...  THEN...  constructs.  The  Information  required  to  make  the  decisions  Is 
gathered  by  calls  to  the  recall,  anatomy  movement.  Information  absorption  and 
mental  computation  micro-models.  Procedural  decisions  (what  procedure  to  work 
on  next)  are  based  on  how  long  It  has  been  since  each  procedure  was  last 
worked  on  and  how  Important  each  procedure  Is. 

The  relaxation  micro-model  functions  In  parallel  with  the  other 
micro-models,  returning  body  parts  to  relaxed  locations  when  they  are  not 
being  used  to  carry  out  procedural  statements. 
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OPERATOR  PROCEDURES  FOR  THE  MAIL  SORTING  SIMULATION 
The  HOPROC  operator  procedures  and  functions  for  the  mail  sorting 
problem  described  in  Section  1.8  are  shown  In  Figure  7. 

Several  things  should  be  noted  about  the  code.  First,  the  statements  * 
are  in  an  English-like  language  and  are  similar  to  the  Instructions  that  one 
might  give  an  operator  who  was  learning  to  use  the  system.  Exactly  what  Is 
expected  of  the  operator  Is  reasonably  clear,  even  without  a  detailed  knowledge 
of  the  language.  Thus,  the  HOPROC  Instructions  could  almost  be  used  as  the 
basis  for  training  operators  In  the  use  of  the  system. 

Second,  there  are  some  things  missing  from  the  code  that  might  seem 
to  be  significant  omissions.  For  example,  there  is  no  mention  of  where  the 
controls  are  located,  what  their  characteristics  are,  how  many  letters  the 
operator  will  have  to  process,  what  the  specific  zip  codes  will  be,  what  the 
actual  sequence  of  button  depressions  will  be,  or  what  any  other  operating 
characteristics  of  the  mall  sorting  machine  or  the  operator  are.  These  factors 
have  been  left  out  of  the  procedural  descriptions  because  they  are  not  significant 
to  the  description  of  the  procedures  that  the  operator  must  follow.  However, 
since  they  do  drive  the  results  that  would  be  obtained  in  an  actual  situation, 
they  are  entered  later  as  Input  data  to  the  simulation  through  the  hardware 
procedures  and  functions  (Figure  8)  and  through  other  direct  Inputs  to  the 
simulation  (Figure  9). 

2.6  THE  OUTPUT  FROM  HOS 

The  primary  output  from  HOS  is  a  time  history  of  operator  activities. 

An  example  of  this  output  for  the  mail  sorting  problem  is  shown  in  Figure  10. 

The  left  hand  column  lists  the  simulation  time,  in  seconds,  for  each  of  the 
operator  activities  listed  In  the  next  column.  The  body  parts  in  use  and  the 
hardware  procedures  being  executed  are  listed  in  succeeding  columns.  Although 
this  example  Is  much  simpler  than  the  average  HOS  simulation.  It  Is  clear  that 
HOS  can  provide  data  to  a  level  of  detail  unmatched  by  any  other  operator 
simulation  technique.  Including  dynamic  simulation. 


OPERATOR  PROCEDURES 
DEFINE  MISSION. 

NEXT i  DEPRESS  THE  FEED-KEY. 

IF  THE  AREA-CODE  IS  191  THEM 
DEPRESS  THE  LOCAL-KEY; 

KEYSET-ENTER  OSINS  THE  CITY-ZONE r  2; 

SO  TO  NEXT. 

KEYSET-ENTER  OSINS  THE  AREA-CODE,  3. 

SO  TO  NEXT. 

DEFINE  THE  PROCEDURE  TO  KEYSET-ENTER  USING  AN  AMOUNT, 
NUNDER-0F-DI8ITS. 

INITIALIZE  THE  COUNT. 

NEXT i  ADD  1  TO  THE  COUNT. 

IF  THE  COUNT  IS  SREATER  THAN  THE 

NUNDER-0F-DI8ITS  THEN  END. 

DETERNINE  THE  NEXT-DIOIT. 

DESIGNATE  IT  AS  THE  KEYSET-NUNDER. 

DEPRESS  THEHCfYSET-NUHDER. 

SO  TO  NEXT. 


OPERATOR  FUNCTIONS 
SO  TO  10000 
9000  CONTINUE 

I»'NUHD£R-OF-DI8ITS'-'COUNT' 

I*'ANQUNT'/(10**I) 

>1/10 

»10 

K-I-J 

'NEXT  DISIT' «N 
C 

I*'ZIP-CODE'/tOO 

'AREA-CODE'*! 

C 

I*'ZIP-C0Di'/100 

I*'ZIP-C0DE'-100*I 

'CITY-ZONE'*! 


Figure  7.  Optra tor  Procedures  and  Functions  for  the  Mall  Sorting  Problem 
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hardware  procedures 

5™T.*"",Mc“r To  ttmun 


hardware  functions 

60  TO  10000 
POOO  CONTINUE 

READ(7,I00)  I2IP 
IF(EOF(7).N£.0)  STOP  5 
ACTUAL ( <ZIP-CODE> ) > IZIP 
100  FORMAT (14) 

'ZIP'*IZIP 


Figure  8.  Hardware  Procedures  and  Functions  for  the  Mall  Sorting  Problem 
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I 


SYSTEM 

NAIL 

METRIC 

0  23 

-30 

DISPLAY  SECTION 

AREA  CODE 

1  0  1 

1  -.7  20  10  1 

CITY  ZONE 

3  4  1 

1  .7  20  10  0 

CONTROL  SECTION 

LOCAL  KEY 

2  0  1 

1  3-300 
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Figure  9.  Crewstatlon  Input  Data  for  the  Mall  Sorting  Problem 
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Finally*  In  addition  to  the  raw  timeline  data  produced  by  H05* 
statistical  analysis  routines  developed  specifically  for  use  with  HQS  can 
produce  a  variety  of  composite  statistics.  Examples  of  the  timeline  and 
channel  loading  analysis  are  shown  In  Figures  11  and  12.  Other  statistical 
analyses  available  Include  device  usage  statistics  and  link  analyses. 


2-16 


f 
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Figure  12.  Channel  Loading  Analysis 
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3.  THE  HOS  OPERATOR  MODELS 


3.1  INFORMATION  ABSORPTION 

3.1.1  Absorption  Modalities 

The  HOS  operator  has  three  modalities  by  which  he  can  obtain 
information  —  his  eyes,  hands,  and  feet.  Currently,  neither  hearing  nor 
speech  nor  any  kinesthetic  cues,  such  as  vibration,  balance,  or  the  per¬ 
ception  of  external  motions  are  simulated  because  of  the  unavailability  of 
any  satisfactory  models  for  the  effects  that  these  factors  have  on  an  operator's 
performance  that  could  be  used  in  HOS. 

When  describing  the  displays  and  controls  in  the  operator's  crew- 
station,  the  analyst  must  identify  the  modality  (eyes,  hands,  or  feet)  that 
the  operator  is  to  use  when  obtaining  information  from  each  device.  Thus, 

If  the  analyst  were  describing  the  displays  and  controls  in  an  automobile,  he 
would  indicate  to  HOS  that  the  operator  is  to  use  his  eyes  to  read  the  fuel 
guage,  his  hands  to  "read"  the  steering  wheel,  and  his  foot  to  "read"  the 
accel era tor. 

The  process  by  which  the  operator  obtains  information  is  the  same 
for  each  modality  and  consists  of  a  series  of  micro-absorptions.  Each 
micro-absorption  requires  time.  As  the  operator  spends  more  time  (more 
micro-absorptions)  reading  a  device,  both  his  knowledge  of  the  device's  value 
and  his  confidence  In  that  knowledge  increase  until  his  confidence  exceeds  a 
threshold,  at  which  time  the  absorption  process  is  terminated.* 


”  *Several  other  conditions  may  cuase  an  absorption  to  be  terminated,  as 
will  be  discussed  below. 
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3.1.2 


Absorption  Hab  Strengths 
The  quantity  that  represents  the  operator's  confidence  in  his 
knowledge  of  the  value  of  a  device  Is  termed  hab  strength,  after  the  learning 
theory  concept  called  "habit  strength"  by  Clark  Hull.  Each  device  has  an 
associated  hab  strength  that  builds  up  during  absorption.  As  the  operator 
spends  more  time  absorbing  information,  the  hab  strength  associated  with 
that  information  increases  until  it  exceeds  a  threshold  value,  at  which  point 
absorption  is  terminated. 


As  an  example,  assume  that  the  operator  is  attempting  to  read  a 
device  (e.g.,  a  warning  light)  that  has  two  discrete  settings  —  on  and  off. 
Successive  micro-absorptions  will  cause  the  hab  strength  to  increase  as  shown 
in  the  upper  dashed  curve  in  Figure  13.  Within  3-4  micro-absorptions,  the 
operator  would  have  established  to  his  satisfaction  whether  the  display  is  on 
or  off  and  the  absorption  process  would  be  terminated.  Using  a  micro-absorption 
time  charge  of  .04  such  a  read  operation  would  require  .12-. 16  seconds*  For 
a  display  that  is  more  difficult  to  read,  more  micro-absorptions  are  required 
to  reach  a  comparable  hab  strength,  as  in  the  second  dashed  curve  for  which 
micro-absorption  time  charge  was  .12.  Similarly,  displays  that  have  more  potential 
values  —  i.e. ,  displays  with  more  settings  or  continuous  displays  —  require 
still  more  micro-absorptions  In  order  to  reach  a  comparable  hab  strength.  The 
bottom  two  curves  shown  in  Figure  13,  for  example,  represent  the  increase  in 
hab  strength  for  two  continuous  displays  with  micro-absorption  time  charges 
equal  to  those  of  the  two  displays  In  the  upper  curves.  It  should  be  noted  that 
the  equations  used  for  continuous  displays  are  the  same  as  those  for  discrete 
displays  with  seven  or  more  settings  —  i.e.,  discrete  displays  with  more  than 
seven  settings  are  treated  as  if  they  were  continuous. 


Figure  14  shows  the  effect  that  the  micro-absorption  time  charge  can 
have  on  the  amount  of  time  spent  In  a  single,  complete  (macro-)  absorption. 

The  four  curves  represent  the  same  four  displays  as  in  the  preceding  figure. 


\s  compared  to  an  average  rate  for  reading  words  of  .17-. 24  seconds  per 


word  based  on  a  reading  rate  of  250-350  wpm. 
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Figure  13.  Hab  strength  as  a  function  of  the  number  of  micro  absorptions. 
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Figure  14.  Hab  strength  as  a  function  of  absorption  time. 


In  Figure  14.  however.  It  can  be  seen  that  If  the  operator  spends  as  much 
as  .4  seconds  In  the  absorption  process,  the  hab  strength  for  the  "easy* 
to-read"  continuous  display  will  exceed  the  hab  strength  for  the  difficult 
discrete  display. 

The  primary  criterion  for  terminating  an  absorption  process  Is 
for  the  hab  strength  of  the  device  value  being  absorbed  to  exceed  a  threshold 
value,  but  there  are  several  other  conditions  that  the  analyst  can  Impose 
as  Input  parameters  that  will  terminate  absorption.  These  conditions  are: 

e  A  maximum  amount  of  time  to  be  spent  absorbing. 

•  A  maximum  number  of  micro-absorptions. 

•  A  tolerance  value  that  specifies  that  the  hab  strength  has 
reached  an  asymptote. 

e  A  tolerance  on  the  accuracy  to  which  the  operator  Is  requried 
to  read  any  device  —  after  which  he  Is  considered  to  “know" 
the  va7ue  of  the  device. 

The  Interaction  between  these  termination  conditions  are  discussed  In  more 
detail  in  Strieb,  Glenn,  and  Wherry  (1978). 

3.1.3  Absorption  Estimates  and  Errors 

During  the  absorption  process,  the  operator  acquires  knowledge 
about  the  value  of  a  device  and  confidence  In  his  knowledge  of  that  value.  The 
value  that  the  operator  believes  a  continuous  device  to  have  (the  estimated  value 
of  the  device)  Is  determined  from  the  aotual  value  of  the  device  by  adding  an 
error  term  that  Is  normally  distributed  about  the  actual  value  and  whose  magnitude 
Is  dependent  upon  an  aeauraay  for  the  device  as  supplied  by  the  analyst.  Thus, 

If  the  analyst  has  specified  that  a  particular  device  can  be  read  to  an  accuracy 
of  two  percent,  then  two  percent  of  the  aqtual  value  of  the  device  Is  used  as 
the  standard  deviation  when  computing  the  value  that  the  operator  believes  the 
device  to  have  on  any  specific  absorption. 
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3.2  INFORMATION  RECALL 

3.2.1  Long-Term  and  Short-Term  Memory 

The  HOS  Information  recall  model  consists  of  two  submodels  —  a 
model  for  short-term  memory  and  one  for  long-term  memory.  The  long-term 
memory  model  Is  currently  limited  to  the  recall  of  certain  types  of  pre¬ 
determined  Information.  Specifically,  the  HOS  operator  is  assumed  to  have 
a  completely  accurate  and  instantaneous  recall  of  the  locations  of  all  the 
displays  and  controls  In  his  crewstatlon,  most  of  their  characteristics ,  the 
procedures  that  must  be  followed  In  carrying  out  a  job,  and  the  calculation 
processes  for  any  mental  computations  that  must  be  performed.  These  assump¬ 
tions  are  consonant  with  the  basic  assumption  of  the  HOS  model  —  namely, 
that  the  operator  being  simulated  is  a  trained  operator  who  performs  routine 
operations  automatically. 

The  short-term  memory  model  is  more  elaborate.  Short-term  memory 
Is  considered  to  be  linked  to  perception  through  the  hab  strength  concept. 

As  explained  above,  during  the  process  of  absorbing  information,  the  operator's 
confidence  In  his  knowledge  of  the  value  of  a  device  Increases  until  it  exceeds 
a  threshold  at  which  point  the  absorption  process  Is  terminated.  The  ultimate 
hab  strength  associated  with  the  device,  a  value  between  zero  and  one,  constitutes 
a  measure  of  the  operator's  confidence  In  his  knowledge  of  the  device  value. 

During  recall,  the  hab  strength  Is  used  to  determine  the  prob¬ 
ability  that  the  operator  will  recall  Information  absorbed  from  a  device.  The 
probability  of  successful  recall  Is  given  by: 

P  «  \f~*~ 

where  H  Is  the  hab  strength  and  t  Is  the  time  In  seconds  since  the  last 
absorption.  Since  H  Is  a  value  between  zero  and  one,  the  probability  of  recall 
Is  one  at  time  zero  —  i.e. ,  the  operator  has  an  Instantaneous  memory  of  the 
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value  of  a  device  that  Is  perfect,  to  the  extent  that  he  has  learned  the 
Information  In  the  first  place.  One  second  after  the  completion  of  an 
absorption,  the  probability  of  recall  Is  exactly  equal  to  the  hab  strength. 

As  soon  as  absorption  Is  complete,  the  probability  of  recall  begins  to 
decay  exponentially  as  shown  In  Figure  15  .  Thus,  within  60  seconds  after 
an  absorption  that  had  raised  the  hab  strength  to  .7,  the  probability  of 
successful  recall  would  be  less  than  .1.  If,  however,  the  hab  strength 
had  been  raised  to  .9,  the  probability  of  recall  would  stay  above  the  level 
.1  for  approximately  seven  minutes.  Figure  15  shows  recall  probabilities 
from  some  of  the  available  experimental  data  on  short-term  memory  and  how 
these  data  correspond  to  various  hab  strength  values.  Based  on  these  data, 
we  have  chosen  .8  as  the  default  value  for  the  hab  strength  threshold  — 
the  value  that  Is  used  to  deteralne  when  the  absorption  process  is  terminated. 

The  value  of  P  from  the  probability  of  recall  equation: 

P  • 

Is  compared  against  a  number  drawn  at  random  from  a  uniform  distribution.  If 
the  randomly  drawn  number  is  less  than  P,  then  the  information  Is  "remembered. " 
If  the  randomly  drawn  number  Is  much  larger  than  P,  then  the  Information  Is 
"forgotten."  If,  however,  the  randomly  drawn  number  Is  close  to  P,  then  the 
model  assumes  that  the  operator  Is  In  a  region  of  "near-recall,"  where  given 
a  little  more  time,  he  might  remember.  A  second  random  number  Is  therefore 
drawn  and  compared  with  P  to  determine  whether  the  Information  Is  remembered, 
forgotten,  or  In  the  near-recall  region.  Usually  a  second  draw  will  suffice  — 
the  random  number  will  either  be  In  the  remembered  or  forgotten  region.  But 
the  process  could  theoretically  go  on  for  three  or  more  tries.  Each  try  results 
In  the  addition  of  a  small  amount  of  time,  the  short-term  memory  ayale  time,  to 
the  total  time  for  retrieval  from  short-term  memory  (Figure  16). 

When  the  operator  recalls  a  value,  the  hab  strength  associated  with 
that  value  Is  changed  In  order  to  simulate  the  effects  of  rshearsal.  The 
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INCE  LAST  ABSORPTION 


remembered  value  is  given  a  hab  strength  that  is  lower  than  if  the 
information  had  been  absorbed  again,  but  higher  than  it  would  have  been 
had  the  normal  decay  curve  been  followed. 


There  are  several  features  of  this  recall  model  that  deserve 
some  comment  (and  probably  some  future  work).  First,  the  process  by  which 
the  hab  strength  associated  with  any  item  of  information  is  increased  and 
recalled  is  independent  of  the  value  of  information  to  the  operator  —  the 
threshold  value  is  the  same  for  all  information  and  consequently  all  items 
of  information  follow  essentially  the  same  curves  for  the  increase  and  decrease 
in  hab  strength.  This  is  clearly  unrealistic  —  information  that  is  of 
greater  value  to  the  operator  should  decay  less  rapidly  and  should  be  learned 
to  a  higher  level  of  confidence  than  less  important  information.  Secondly, 
the  recall  model  has  no  explicit  provision  for  allowing  information  to  transfer 
from  short-term  memory  to  long-term  memory,  though  there  is  an  effective 
transfer  that  results  from  rehearsal  for  the  real  human  operator.  Third,  there 
Is  no  linkage  between  items  of  information  —  if,  for  example,  the  operator 
depresses  a  switch  that  changes  the  value  of  a  display,  that  action  will 
normally  not  affect  the  value  that  the  simulated  operator  will  recall  for  the 
display,  whereas  a  true  operator  would  certainly  know  that  the  displayed  value 
had  changed.*  And  fourth,  there  are  no  external  cues  that  Impact  the  perceived 
or  recalled  value  of  a  device,  as  the  view  out  the  window  might  cue  the  recall 
of  the  altimeter  value  for  an  aircraft  pilot. 

3.2.2  Errors  During  Recall 

For  continuous  devices,  there  is  a  portion  of  the  recall  model 
that  simulates  the  decreased  accuracy  associated  with  the  recalled  value. 

The  basic  premise  behind  this  feature  of  the  recall  model  is  that  as  con¬ 
fidence  (l.e. ,  hab  strength)  in  the  value  of  a  device  decreases,  the  pre¬ 
cision  of  the  value  that  the  operator  recalls  for  the  device  will  also  decrease. 
Thus,  If  at  some  later  time,  the  operator  Is  asked  for  the  value  of  the  device, 
then  the  operator  will  be  able  to  supply  fewer  “significant  digits"  as  the 

*A1 though  the  analyst  can,  in  fact,  specify  that  such  linkages  exist 
when  coding  the  procedures. 
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time  frail  the  last  absorption  of  the  value  of  the  device  Increases.  We 
tern  this  process  modular  deeay.  The  modular  decay  function  Is  such  that 
given  an  Initial  device  value  of,  for  example,  123456  and  an  Initial  hab 
strength  of  .8,  the  modularly  decayed  values  would  be  as  shown  In  Figure  17  . 

3.2.3  Extrapolation  of  Values 

If  the  operator  can  recall  the  value  that  a  continuous  device 
had  the  last  time  he  read  It,  then  HOS  enables  the  operator  to  extrapolate 
Its  value  to  the  current  time.  The  extrapolation  Is  linear  and  based  on 
the  two  preceding  absorbed  values  and  the  times  when  those  values  were 
obtained.  It  Is  the  responsibility  of  the  HOS  user  to  declare  whether  or 
not  extrapolation  Is  to  be  permitted  for  each  device. 

3.2.4  Scope  of  the  Information  Absorption  and  Recall  Models 

The  estimated  value  of  a  device  Is  the  only  characteristic  of  a 
device  that  Is  either  recalled  or  read  by  the  HOS  operator.  The  operator 
does,  however,  maintain  other  Information  on  other  device  characteristics  ~ 
desired  values,  upper  limits,  lower  limits,  etc.  —  but  these  quantities 
(termed  device  parameters)  are  considered  to  be  resident  In  the  operator's 
long-term  memory  and  therefore  are  not  subject  to  the  information  absorption/ 
recall  processes.  The  various  device  parameters  are  listed  In  Figure  18. 

3.3  MENTAL  COMPUTATION 

The  mental  calculations  performed  by  the  HOS  operator  are  termed 
operator  functions,  or  simply  functions. 

The  mental  calculation  micro-model  uses  the  hab  strength  construct 
In  much  the  same  way  as  the  Information  absorption  and  Information  recall 
micro-models.  The  result  of  a  mental  computation  has  an  associated  hab 
strength  that  represents  the  operator's  confidence  In  the  computed  data.  As 
the  operator  spends  more  time  on  the  computation,  his  confidence  In  his  estimate 
Increases  until  either: 
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•  OESIREO  VALUE 

•  RATE  OF  CHANGE 

•  TIME  (OF  LAST  ESTIMATE) 

•  X  AND  Y  COMPONENTS 

•  UPPER  AND  LOWER  LIMITS 

•  CRITICALITY 

•  STATE  (ACTIVE  OR  INACTIVE) 

•  ESTIMATED  VALUE 


Figure  18.  Davie*  Parewatare 
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•  The  hab  strength  threshold  Is  exceeded. 

•  The  hab  strength  has  asymptoted. 

•  The  maximum  number  of  Interactions  through  the  hab 
strength  Incrementing  process  has  been  exceeded. 

•  The  amount  of  time  spent  In  computation  exceeds  a  maximum 
allowable  computation  time. 

The  recall  model  for  mentally  computed  data  is  Identical  to  the  model  used 
for  any  other  type  of  data. 

The  basic  difference  between  the  mental  computation  model  and 
the  Information  absorption  model  Is  that,  in  the  latter,  information  is 
absorbed  from  a  display  or  control  in  the  crewstation,  whereas  In  the  former, 
displayed  information  is  used  to  determine  a  value  that  is  not  displayed 
anywhere  in  the  crewstation.  For  example,  a  typical  mental  computation 
when  driving  an  automobile  is  determining  how  much  farther  one  can  go  on  a 
tank  of  gas.  The  computation  requires  the  absorption  of  an  item  of  informa¬ 
tion  (the  amount  of  fuel  remaining)  coupled  with  some  prior  knowledge  (the 
number  of  miles  per  gallon). 

When  a  mental  calculation  Is  required,  HOS  will  determine  what 
Information  is  needed  In  order  to  perform  the  calculation.  If  the  HOS 
operator  can  remember  the  Information,  the  calculation  Is  performed  at 
once.  If  he  cannot  remember  the  Information,  an  appropriate  sequence  of 
actions  Is  Initiated  to  enable  the  operator  to  obtain  che  data.  In  the  above 
example,  the  displayed  information  required  is  the  amount  of  fuel  remaining. 
If  the  operator  cannot  remember  this,  HOS  would  cause  him  to  look  at  the  fuel 
gauge  and  read  Its  value. 

Each  mental  calculation  can  require  as  many  as  ten  different  data 
Items.  These  may  be  the  values  of  displays  or  controls  or  the  results  of 
other  mental  calculations.  An  unlimited  number  of  parametric  values  are 
also  allowed.  The  amount  of  time  required  for  a  mental  calculation  Is 


considered  to  be  the  amount  of  time  required  to  gather  all  the  Items  of 
information  needed  for  the  calculation  plus  some  additional  time  to  "put 
it  all  together."  Because  of  the  high  potential  variability  in  a  function 
calculation,  the  analyst  Is  required  to  supply  a  function  computation  time 
for  each  function  —  HOS  itself  will  supply  the  times  required  to  gather 
all  the  Items  of  information  needed  for  the  calculation. 

A  second  difference  between  the  mental  computation  and  Information 
absorption  models  Is  that  In  the  Information  absorption  model,  the  minimum 
hab  strength  associated  with  a  device  Is  dependent  on  the  number  of  settings 
associated  with  the  device.  In  the  case  of  mental  computations,  the  hab 
strength  associated  with  the  operator  function  is  the  minimum  hab  strength 
associated  with  any  of  the  components  in  the  function  claculatlon. 

Errors  In  mental  computation  are  assumed  to  be  the  result  of 
errors  associated  with  the  data  that  goes  Into  the  calculation  itself.  The 
calculation  process  Itself  Is  considered  to  be  error-free.  Thus,  If  the 
operator  makes  an  error  or  obtains  an  Inaccurate  data  value  when  either  recal¬ 
ling  the  data  or  reading  the  data  needed  for  a  calculation,  then  the  result  of 
the  calculation  will  be  Incorrect,  or  Inaccurate,  according  to  the  incorrect¬ 
ness  or  Inaccuracy  of  the  incoming  data.  If  the  data  values  are  correct  and 
accurate,  then  the  result  of  the  calculation  will  be  accurate.  It  should  be 
noted,  however,  that,  as  a  result  of  the  way  In  which  mental  calculations 
are  described  to  HOS,  the  analyst  has  the  ability  to  Inject  errors  Into  the 
function  calculation  If  he  so  chooses. 

3.4  MAKING  A  DECISION 

HOS  decision-making  takes  place  at  two  levels  —  the  inter-procedural 
and  the  Intra-procedural  levels.  A  procedure  is  an  operator  took  consisting 
of  any  matter  of  etepe,  any  step  of  which  can  Invoke  the  execution  of  another 
procedure  or  any  other  operator  action.  For  example,  the  operator's  mission 
In  any  particular  simulation  Is  a  procedure  that  invokes  other  procedures  — 
a  pilot's  mission  may  Invoke  a  procedure  for  takeoff,  another  for  cruise. 
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another  for  landing,  etc.  Within  these  procedures  (or  any  procedures  that  they 
invoke)  there  are  steps  that  describe  operator  actions  —  reading  a  display, 
adjusting  a  control,  etc.  Decision-making  can  therefore  operate  at  two 
different  levels  —  deciding  what  procedure  to  perform  from  a  set  of  available 
active  procedures,  or  deciding  what  to  do  next  within  any  particular  procedure. 

HOS  gives  the  analyst  the  option  of  both  limited  and  total  control 
over  these  decisions.  The  analyst  can  opt  for  total  control  in  the  sense 
that  simulations  can  be  constructed  that  force  the  operator  to  follow  a 
specific  sequence  of  steps  and  procedures.  The  analyst  can,  instead,  choose 
limited  control  in  the  sense  that  the  exact  sequence  of  task  and  subtask 
operations  that  an  operator  will  use  is  unknown  —  the  simulation  can  be 
constructed  so  that  the  HOS  operator  is  allowed  to  make  decisions  for  him¬ 
self  In  accordance  with  a  flexible  task  structure.  Such  a  flexible  structure 
is  appropriate  because,  like  a  real  operator,  HOS  can  adapt  its  actions  to 
situations.  The  power  of  HOS  lies  in  its  ability  to  adapt  its  performance  to 
situations  in  a  natural  and  realistic  fashion. 

Decisions  about  what  to  do  next  within  a  procedure  are  fairly  simple. 
HOS  will  attempt  to  execute  each  step  in  a  procedure  in  sequence  until  it  can 
go  no  further,  for  whatever  reason.  If  it  finds  itself  blocked,  it  will  attempt 
to  "unblock"  itself.  If  It  can.  It  will  continue  with  the  next  procedural 
step;  if  it  can't,  it  will  look  for  some  other  procedure  to  work  on,  at  which 
point  the  decision-making  logic  for  selecting  a  procedure  is  invoked. 

As  it  executes  the  steps  In  a  procedure,  HOS  may  encounter  a  state¬ 
ment  that  requires  a  decision,  i.e.,  an  IF  statement.  The  IF  statement  requires 
the  operator  to  make  a  decision  about  the  current  status  of  Information  or 
events  in  the  simulation.  If  the  condltlon(s)  tested  is  (are)  satisfied,  then 
It  proscribes  a  set  of  actions  to  be  taken.  If  the  condltion(s)  is  (are) 
not  satisfied,  the  actions  are  not  performed.  A  small  time  charge  is  assessed 
for  this  decision-making  function  over  and  above  the  time  charges  associated 
with  gathering  the  information  needed  for  the  decision. 


There  are  basically  three  types  of  events  that  will  block  the 

operator: 

(1)  An  action  Is  required  that  the  operator  cannot  perform 
because  the  action  requires  body  resources  that  are  busy 
doing  something  else, 

(2)  The  operator  requires  information  that  is  currently  unavail¬ 
able  because  a  device  is  inactive  (not  enabled),  or 

(3)  The  operator  must  perform  a  control  action  that  cannot  be 
performed  because  the  control  is  Inactive  (not  enabled). 


Of  these  situations,  the  latter  two  are  the  more  conmon.  When 
they  occur,  HOS  will  automatically  invoke  a  special  type  of  procedure  — 
an  triable  procedure  —  whose  function  is  to  activate  the  device  that  is 
Inactive.  When  the  first  situation  occurs,  HOS  will  simply  go  off  and  work 
on  another  procedure  until  the  required  body  part  is  free. 

One  of  the  actions  that  can  be  performed  within  a  procedure  is  the 
Invocation  of  another  procedure.  When  a  procedure  Is  Invoked,  the  analyst 
can  specify  either  that: 

(1)  The  procedure  Is  to  be  executed  Inmediately  and  no  more 
steps  In  the  current  procedure  are  to  be  executed  until 
the  Invoked  procedure  has  been  completed,  or 

(2)  The  Invoked  procedure  Is  to  be  placed  on  an  active  procedure 
liet  and  is  to  be  executed  as  soon  as  appropriate,  or 

(3)  The  Invoked  procedure  Is  to  be  executed  periodically  until 
removed  from  the  active  procedure  list. 


In  situation  (1),  control  transfers  imnedlately  to  the  Invoked  pro¬ 
cedure  and  no  more  steps  In  the  Invoking  procedure  are  executed  until  the 
invoked  procedure  Is  completed.  The  active  procedure  list,  formed  by  invoking 
procedures  by  methods  (2)  and  (3),  is  the  list  of  procedures  available  to  the 
operator  when  he  finds  himself  blocked  In  his  current  procedure.  Procedures 
placed  on  the  active  procedure  list  by  method  (3)  are  called  monitor  procedures 
In  that  they  are  usually  used  to  cause  the  operator  to  periodically  monitor 
a  particular  display  or  control . 


Finally,  the  analyst  can  force  a  procedure  to  be  selected  from  the 
active  procedure  by  using  special  forms  of  the  IF  and  GO  TO  statements. 

When  a  procedure  Is  to  be  selected  from  the  active  procedure  list, 
a  model  that  represents  the  operator's  procedural  selection  process  Is  Invoked. 
This  model  considers  two  factors: 

(1)  The  criticality  (priority)  of  the  procedure,  and 

(2)  How  long  It  has  been  since  the  procedure  was  last  executed. 

A  detailed  discussion  of  the  interaction  of  these  factors  is  pre¬ 
sented  in  Strieb,  Glenn,  and  Wherry  (1978).  Briefly,  as  the  length  of  time 
since  the  procedure  was  last  executed  increases,  the  effective  criticality 
of  the  procedure  increases  (over  an  initial  criticality  that  can  be  set  by 
the  analyst),  as  shown  in  Figure  19.  In  addition,  for  monitor  procedures, 
the  effective  criticality  is  further  modified  by  a  factor  that  is  dependent  on 
how  close  the  device  being  monitored  is  to  a  defined  set  of  limits.  As  the 
estimated  value  of  the  device  approaches  its  limits,  the  effective  criticality 
of  the  device  increases.  When  it  exceeds  the  defined  limits,  the  effective 
criticality  increases  very  rapidly,  as  shown  in  Figure  20.  The  computed 
effective  criticalities  for  each  procedure  on  the  active  procedure  list  are 
compared  and  the  procedure  with  the  highest  effective  criticality  is  chosen  as 
the  next  procedure  to  work  on. 

3.5  ANATOMY  MOVEMENT 

The  anatomy  movement  micro-model  is  almost  always  accessed  implicitly  - 
i.e.,  the  analyst  will  rarely  issue  a  command  that  will  force  a  body  movement. 
Rather,  HOS  itself  will  determine  whether  a  body  movement  is  required  in  order 
to  accomplish  the  objective  of  an  instruction.  If  it  decides  that  a  body 
movement  is  required,  HOS  will  automatically  select  the  appropriate  body 
part,  move  it  to  the  required  location,  and  add  to  the  simulation  time  a  com¬ 
puted  estimate  of  the  amount  of  time  the  action  would  have  taken  a  real  operator. 
For  example,  suppose  a  procedural  statement  says: 

TURN  SWITCH-A  ON. 


3-17 


TIME  SINCE  LAST  EXECUTED 

Figure  IS.  lucre—  in  Procedural  Criticality  with  Tima 


SSTtMATSD  VALUE  -  2*  UPPER  LIMIT 

ESTIMATEO  VALUE  ■  UPPER  LIMIT 


i  1  "I  '  i  ~~  i  — i  —  ■  — 1  r 

20  30  40  SO  60 

TIME  SINCE  LAST  EXECUTED 

Figure  20.  Increase  in  Criticality  for  Monitor  Procedural 
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If  HOS  decides  that  this  action  Is  necessary,*  and  If  one  of  the  operator's 
hands  Is  not  already  on  SWITCH-A,**  HOS  will  select  a  hand,  "move"  It  to 
SWITCH-A,  and  charge  and  amount  of  time  equal  to  the  time  that  a  real  operator 
would  have  taken  to  move  that  hand  to  SWITCH-A  from  wherever  the  hand  was  at  the 
time  the  Instruction  was  Issued. 

Thus,  the  moving  and  grasping  primitive  function  consists  of  two 
micro-models  —  one  to  determine  which  body  part  to  use  for  a  particular 
action,  the  other  to  assign  a  time  charge  for  the  movement.  The  body  part 
selection  micro-model  Is  based  on  several  common-sense  principles.  The  first 
is  that  the  body  part  to  be  used  is  determined  by  the  function  to  be  performed 
and  the  device  being  referenced.  Thus,  If  the  operator  is  going  to  be  reading 
data  from  a  device,  the  eyes  are  usually  the  appropriate  body  part  to  use. 
However,  there  may  be  some  devices  whose  value  cannot  be  determined  visually  — 
touching  them  with  a  hand  or  foot  may  be  more  appropriate.  Some  devices  may 
use  two  modalities  —  the  eyes  are  used  to  absorb  information  while  the  hands 
are  used  when  the  device  is  to  be  altered.  HOS  permits  the  analyst  to  specify 
for  each  device  the  most  appropriate  modality  for  each  function  (reading  and/or 
al terlng). 


If  the  operator's  eyes  are  to  be  used  for  a  specific  function, 
there  Is  no  problem  —  the  HOS  operator  has  only  one  pair  of  eyes  which  are 
Immediately  moved  to  the  device.  The  time  charge  assigned  for  an  eye  movement 
Is  computed  from  an  equation  that  was  developed  by  fitting  the  data  from  an 
experlement  that  Involved  lateral  eye  movements  (Dodge  and  Cline,  1901)  and 
from  an  unpublished  experiment  by  Wherry  and  Bittner  that  involved  both  lateral 
and  convergence  movements. 


*SWlYCH-A  may  be  ON.  A  real  operator,  if  he  remembered  this,  would  not 
perform  the  action.  Similarly,  HOS  would  decide  whether  the  simulated  operator 
remembered  whether  the  device  was  on  and.  If  he  did,  would  not  Initiate  the 
body  movement. 

♦♦Assuming  that  SWITCH-A  Is  a  device  that  Is  turned  on  by  hand. 
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The  equations  used  are: 
T  »  .14324  A  +  .0175 


where 

A  »  max  (A6»  44)  *  .2  rain  (48,  44) 
and 

P,  P2 

44  «  I  tan'1  (7375)  -  tan'1  (7373-)  I 
P  P 

*•  •  1  <TT^nrjr)  1 

p.j  •  vector  frora  design  eye  point  to  fixation  point  1 
?2  m  vector  from  design  eye  point  to  fixation  point  2 

These  equations  assume  that  both  the  lateral  and  convergence  movements  can 
proceed  concurrently  with  the  total  movement  time  being  dependent  on  which 
movement  takes  the  greater  amount  of  time. 


When  one  of  the  operator's  hands  Is  needed,  HOS  must  decide  which 
hand  to  use  for  the  action.  The  logic  that  HOS  uses  is  as  follows: 

(1)  It  will  attempt  to  use  the  hand  that  Is  currently  closer  to 
the  device,  unless  that  hand  is  currently  busy  doing  something 
else. 

(2)  If  the  preferred  hand  Is  busy,  but  will  be  free  "soon,"  where 
"soon"  is  the  amount  of  time  that  can  be  set  by  the  analyst, 
then  HOS  will  “wait"  until  the  preferred  hand  is  free  and  will 
then  “move"  the  operator's  hand  to  the  device. 

(3)  If  the  preferred  hand  will  not  be  free  soon,  then  the  operator's 
other  hand  Is  used  —  assuming  that  It  Is  free  and  can  reach 
the  device. 

(4)  If  the  operator's  other  hand  is  not  free,  but  will  be  soon, 

HOS  will  again  wait  until  that  hand  Is  free  and  then  use  It. 
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(5)  If,  however,  the  operator's  other  hand  cannot  reach  the  device, 
then  a  determination  Is  made  as  to  whether  a  hand  swap  should 
be  Initiated.  In  a  hand  swap,  the  less  preferred  hand  takes 
over  the  function  being  performed  by  the  preferred  hand  so  that 
the  operator  can  move  the  preferred  hand  to  the  device. 

(6)  If  both  hands  are  busy  and  won't  be  free  for  some  time,  or  If 
a  hand  swap  cannot  be  performed,  HOS  will  decide  that  the 
Instruction  Is  unexecutable  and  will  delay  the  execution  of 
the  procedure  In  which  that  statement  Is  found  until  one  of 
the  operator's  hands  Is  free. 


Similar  logic  pertains  to  the  use  of  the  operator's  feet  with  the 
exception  that  "swaps"  cannot  take  place. 

The  time  required  for  a  hand  or  foot  movement  Is  assumed  to  depend 
on  both  the  magnitude  and  the  precision  of  the  movement.  The  equations  that 
determine  how  long  a  hand  movement  will  take  are  a  combination  of  the  results 
of  experiments  by  Fitts  (.1954)  and  by  Topmlller  and  Sharp  (1965)  are  discussed 
tn  detail  In  Strieb,  Glenn,  and  Wherry  (1978).  These  data  are  shown  In  Figure 
2)  where  they  are  compared  with  other  hand  movement  studies.  The  same  equa¬ 
tions  are  also  currently  being  used  for  foot  movements,  but  with  different  basic 
parameter  values. 


Some  key  characteristics  of  the  anatomy  movement  micro-model  that 
should  be  noted  here  are: 

(1)  Movements,  like  the  Instructions  that  initiate  them,  are 
executed  serially  for  each  body  part. 

(2)  Movements  are  ballistic  —  once  Initiated  they  cannot  be 
stopped  nor  can  another  action  be  Initiated  while  the  movement 
Is  taking  place. 

(3)  Movement  times  are  fully  deterministic,  based  on  where  a 
body  part  Is  and  where  It  Is  being  moved  to  —  there  Is  no 
variability. 

(4)  If  a  movement  cannot  be  performed,  an  Interrupt  will  be 
generated  enabling  the  operator  to  select  another  procedure 
from  the  active  procedure  list  for  execution. 
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it  Timet  at  a  Function  of  Distance 


3.6  PERFORMING  A  CONTROL  MANIPULATION 

Times  associated  with  control  manipulations  are  highly  variable 
because  of  the  diverse  types  of  controls  used  in  different  operator  stations 
Consequently,  HOS  allows  the  user  to  describe  the  characteristics  of  a  con¬ 
trol  which  are  used  to  determine  a  set  of  equations  that  describe  the  time 
associated  with  a  control  manipulation.  In  addition,  there  are  a  set  of 
"packaged"  calculations  that  compute  control  manipulation  times  for  two 
basic  control  types  —  discrete  controls  and  continuous  rotary  knobs. 

For  discrete  controls,  the  analyst  is  required  to  supply  a  time 
that  represents  the  time  required  to  move  the  control  through  a  single 
setting.  If  a  control  manipulation  results  in  a  movement  through  several 
settings,  the  time  assigned  will  be  the  time  required  for  a  single  setting 
multiplied  by  the  number  of  settings. 

The  formula  for  the  manipulation  time  for  a  continuous  rotary 
control  was  derived  by  fitting  a  quadratic  to  a  table  of  data  presented  by 
Karger  and  Bayha  (1966).  The  resultant  formula  is: 

T  *  .0482  +  .0050F  +  .0084  FA 

where  F  is  the  force  In  pounds  required  to  turn  the  control  and  A  Is  the 
angle  through  which  the  control  Is  to  be  turned.  In  radians. 

Unlike  some  of  the  other  actions  that  we  have  discussed  —  Informa 
tlon  absorption,  recall,  anatory  movement,  etc.  —  once  initiated,  control 
manipulations  can  proceed  In  parallel  with  other  actions.  Thus  the  operator 
am  be  performing  manipulations  concurrently  with  both  his  right  and  left 
hands . 
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3.7  RELAXATION 

The  HOS  relaxation  micro -model  Interfaces  with  all  the  other  action 
micro-models.  Though  fatigue  Itself  Is  not  currently  modeled,  HOS  does 
exhibit  one  related  characteristic  that  a  real  operator  tends  to  exhibit  ~ 
when  body  parts  are  not  busy  doing  anything  else,  the  operator  will  move  them 
to  a  comfortable,  relaxed  location.  •  The  analyst  can  override  this  default 
location  by  specifying  a  grasp  location  —  a  location  at  which  some  action 
Is  expected.  But  after  the  operator  has  performed  an  action  at  the  grasp 
location,  the  appropriate  body  part  will  automatically  return  to  Its  relaxed 
location. 

This  logic  Is  sumnarlzed  In  Figure  22.  Any  action  establishes  a 
location  to  which  the  operator  must  move  In  order  to  carry  out  the  action. 

After  the  action  has  been  carried  out  (and  after  a  specified  Interval  of  time 
has  elapsed),  the  body  part  will  return  to  the  grasp  location  (If  one  has  been 
established)  or  to  the  relaxed  location.  If  no  other  actions  require  that  body 
part.  After  an  action  occurs  at  the  grasp  location,  that  location  Is  eliminated, 
and  body  parts  return  to  the  relaxed  location. 

3.8  OPERATOR  VARIABILITY 

As  described  above,  most  of  the  equations  that  govern  the  operator 
micro-models  In  HOS  are  fully  deterministic.  This  Is  consistent  with  two 
of  the  premises  In  the  HOS  model  —  that  the  operator  Is  a  trained  operator 
and  that  performance  variations  observed  In  experiments  on  Individual 
operators  are  largely  the  result  of  situational  differences,  as  opposed  to 
differences  In  basic  performance  parameters.  However,  there  are  clearly 
differences  In  operator  performance  —  both  between  operators  and  for  the 
same  operator  under  different  operational  conditions.  Some  of  the  HOS 
operator  parameters  mentioned  above  enable  the  analyst  to  examine  the 
effects  of  such  differences  —  the  short-term  memory  cycle  time,  hab  strength 
threshold,  etc.  In  addition,  by  modifying  the  equations  described  above, 
one  can  readily  describe  an  operator  with  a  different  performance  profile. 


/DESIRED  LOCATION 
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BODY  PARTS  RETURN  TO  A  RELAXED  LOCATION  WHEN  NOT  IN  USE. 

A  "GRASP"  LOCATION  CAN  BE  ASSIGNED  THAT  TEMPORARILY  OVER¬ 
RIDES  THE  RELAXED  LOCATION 

Figure  22.  Relaxation  Logic 
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Finally,  there  Is  a  HOS  construct  that  was  a  part  of  the  original  concept 
of  HOS  that  was  Intended  to  model  such  performance  differences  under 
differing  Internal  and  external  states.  However,  the  operator  states 
(o-states)  concept  has  not  yet  been  Implemented  because  of  the  challenge  that 
has  so  far  confronted  us  In  modeling  average  performance  when  no  special 
stresses  are  Influencing  the  operator. 
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4.  SUMMARY 


4.1  VALIDATION 

Validation  of  any  complex  model  (and  particularly  a  Monte  Carlo 
simulation  model  like  HOS)  Is  fraught  with  difficulties.  One  can  argue 
that  models  can  never  be  fully  validated  —  the  best  one  can  hope  for  Is  that 
In  specific  situations*  given  well-defined  sets  of  Inputs,  the  model  can  be 
shown  to  produce  the  outputs  that  match  expectations,  experience  and  available 
data.  The  problem  Is  even  more  complex  with  a  model  like  HOS  because,  unlike 
simulation  systems  that  manipulate  the  user's  model  of  a  situation  (l.e., 
the  Inputs)  according  to  Incontrovertible  mathematical  formulae.  In  HOS  there 
Is  both  the  HOS  model  of  the  operator  and.  the  user's  model  of  how  the  system 
functions  and  how  the  operator  will  utilize  It.  Both  models  must  be  valid 
for  the  results  of  any  particular  simulation  to  be  valid.  But  since  human 
behavior  Is  so  complex,  one  can  never  be  sure  that  all  possible  circumstances 
have  been  fully  described  and  all  possible  alternatives  foreseen.  It  Is 
therefore  almost  Impossible  to  validate  any  specific  model. 

Notwithstanding  these  difficulties,  efforts  have  been  made  to  ensure 
both  the  validity  of  the  HOS  operator  model  and  the  reasonableness  of  the  out¬ 
puts  obtained  from  specific  user  models.  Tests  of  the  validity  of  the  HOS 
model  have  Involved  simulations  of  specific  experiments  drawn  from  the  human 
factors  and  experimental  psychological  literature  (Strleb,  et.al.,  1975,  Glenn, 
Strleb  and  Wherry,  1977;  Lane,  Strleb  and  Wherry,  1977).  User  model  validations 
have  Included  simulations  of  specific  Navy  crewstatlons  (Strleb,  et.al.,  1976; 
Strleb,  et.al.,  1976;  Strleb,  et.al.,  1978;  Strleb  and  Harris,  1978;  Lane, 
Strleb,  and  Leyland,  1979;  Lane,  Leyland  and  Strleb,  1978).  Both  types  of 
simulations  have  confirmed  the  general  validity  of  HOS. 


4-1 


Although  comparing  model  results  with  experimental  data  has  generally 
been  straightforward,  validation  of  the  model  In  complex  military  situations 
has  been  problematical  because  of  the  difficulties  associated  with  attempting 
to  capture  all  the  potentially  significant  variables  In  the  simulation.  The 
converse  of  this  problem  Is  also  true  ~  one  can  establish  a  scenario  that  can 
be  run  through  HOS,  but  it  Is  difficult  (If  not  Impossible)  to  set  up  real- 
world  situations  (e.g.,  at-sea  exercises)  that  will  conform  to  the  hypothetical 
situations  modeled  In  the  simulations.  Further  confirmation  of  the  HOS  model 
Is  expected  as  the  result  of  a  series  of  HOS  simulations  coupled  with  labora¬ 
tory  experiments  that  are  currently  In  the  planning  stages.  These  simulations 
will  attempt  to  ensure  the  validity  of  the  model  (and  will  determine  the 
values  of  certain  input  data  quantities  needed  by  the  model)  for  a  range  of 
situations  of  varying  complexity  comnonly  experienced  in  Naval  weapons 
systems.  In  addition,  an  effort  Is  currently  underway  with  NASA  Cangley  that 
will  test  a  HOS  pilot  model  through  Its  conformance  with  visual  performance 
data  collected  by  Spady  and  Kurbjun  (1978). 

4.2  ADVANTA6ES  OF  THE  HOS  METHOO 

Since  HOS  Is  basically  an  elaboration  and  formalization  of  task 
analytic  techniques.  It  canbeused  for  everything  that  task  analysis  can 
be  used  for.  But  HOS  has  several  advantages  over  task  analysis.  First,  it 
ensures  a  consistent  level  of  description  for  all  the  tasks  to  be  performed 
by  the  operator  —  or  at  the  least.  It  makes  clear  situations  in  which  the 
task  descriptions  are  not  at  the  same  level  of  description.  Inconsistencies 
In  the  level  of  detail  can  be  a  significant  problem  with  standard  task 
analytic  techniques  because  task  analysis  In  general  does  not  have  a  sufficiently 
well  defined  structure  to  ensure  a  consistent  level  of  description.  Second, 
unlike  task  analyses,  HOS  enables  the  dynamics  of  the  situation  to  be  simulated. 
Simulation  permits  the  critical  factors  in  system  performance  to  be  examined 
under  controlled  conditions.  The  analyst  can  completely  control  not  only  the 
rules  under  which  the  operator  performs,  but  also  the  behavior  of  the  external 
world.  Furthermore,  unlike  experimental  techniques,  the  results  of  HOS 
simulations  are  fully  replicable  so  that  the  effects  of  modifications  to  the 
operator  tactics  or  crewstatlon  configurations  can  be  thoroughly  evaluated. 
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POTENTIAL  USES  OF  THE  HOS  MODEL 


Perhaps  the  best  way  to  demonstrate  the  potential  uses  of  HOS  Is 
to  Indicate  some  of  the  functions  It  can  perform  at  various  stages  In  the 
system  design  process. 


In  the  ayatem  definition  phase,  HOS  can  be  used  to  help  define  the 
functional  requirements  of  the  system.  These  include  the  identification  of 
these  functions  to  be  assigned  to  man  versus  machine,  as  well  as  the  functional 
requirements  that  the  system  itself  must  meet  in  order  to  satisfy  its  mission 
goals. 


In  the  ayatem  design  phase,  HOS  can  serve  both  as  the  repository  for 
data  on  the  proposed  system  design  specifications  as  well  as  a  means  of  evalua¬ 
ting  proposed  designs. 

In  the  8yatem  development  phase,  HOS  can  be  used  to  develop  standard 
procedures  for  the  employment  of  the  system  and  to  evaluate  proposed  tactics  for 
the  utilization  of  system  capabilities. 

In  the  ayatem  teat  phase,  HOS  can  be  used  to  define  the  operator 
training  requirements  associated  with  the  use  of  the  system.  It  can  also 
provide  objective  standards  against  which  achieved  operator  performance  can 
be  measured. 

Finally,  in  the  ayatem  evaluation  phase,  HOS  can  help  to  provide 
insight  into  the  types  of  decision  and  performance  aids  that  would  help  to 
Improve  operator  performance.  It  can  be  used  to  evaluate  the  performance 
Improvements  that  would  be  obtained  with  such  aids,  thereby  facilitating 
re-designs  and  re-deflnltlon  of  existing  system  and  the  design  and  definition 
of  new  systems. 
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HOS  is  not  an  easy  tool  to  usa.  It  demands  a  disciplined  approach 
to  the  Identification  and  characterization  of  system  parameters.  And  it 
requires  a  heavy  Investment  of  time,  money  and  analytical  talents.  But  It 
Is  not  just  a  tool  for  human  factors  engineers.  Rather,  It  is  a  tool  that 
can  benefit  a  variety  of  users  at  various  stages  of  system  design.  It 
provides  a  method  for  coordinating  their  efforts,  yielding  results  that  could 
not  be  obtained  by  any  other  means,  and  thereby  justifying  the  effort  required. 

4.4.  AN  EXAMPLE  OF  THE  USE  OF  HOS  IN  EVALUATING  SYSTEM  DESIGN 

So  far,  HOS  has  been  applied  primarily  to  the  evaluation  of  current 
systems.  Some  of  these  efforts  have,  however,  indicated  how  valuable  the 
timely  application  of  the  HOS  model  would  be  In  evaluating  proposed  system 
design  modifications.  In  particular,  one  recent  effort  (Strieb,  et.al,  1978; 
Strleb  and  Harris,  1978;  Lane,  Leyland  and  Strieb,  1978;  Lane,  Strieb  and 
Leyland,  1979)  studied  several  alternative  configurations  of  the  non-acoustic 
sensor  operator's  station  on  the  Navy's  P-3C  Anti-Submarine  Warfare  (ASW) 
aircraft.  The  simulations  modeled  the  activities  of  the  non-acoustic  operator 
during  a  reconnaissance  mission  similar  to  those  currently  flown  in  the 
Mediterranean.  In  one  simulation,  the  crewstation  was  configured  as  a  "base¬ 
line"  P-3C  aircraft.  In  a  second  simulation,  the  operator  was  given  an 
additional  capability  —  a  manually  controlled  forward  looking  infrared  (FLIR) 
system.  In  the  third  simulation,  the  operator  was  given  an  automated  FLIR 
system.  Comparisons  of  the  simulation  results  indicated  the  extent  to  which 
the  operator's  performance  on  other  tasks  was  degraded  when  the  manual  FLIR 
system  was  used.  The  simulations  clearly  showed  that  not  only  was  the  operator 
unable  to  maintain  satisfactory  performance  on  his  other  tasks,  but  also 
that  the  operator  was  unable  to  use  the  manual  FLIR  system  to  obtain  the 
additional  data  for  which  the  system  had  been  Intended.  The  automated  FLIR 
rectified  these  problems. 

The  simulations  demonstrated  that,  had  HOS  been  used  to  evaluate 
each  configuration  before  it  was  Introduced  to  the  fleet,  an  unacceptable 
configuration  could  have  been  avoided,  thereby  saving  substantial  sums  of 
money.  The  conclusions  reached  from  these  simulations  were  confirmed  by 
reports  from  the  fleet. 
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4.5  CONCLUSIONS 

HOS  Is  a  powerful  technique  for  evaluating  proposed  designs  for  complex 
systems.  The  method  has  been  shown  to  produce  realistic  assessments  of  operator 
taskload  demands  and  overall  system  performance.  The  technique  Is  one  that 
should  be  used  throughout  the  system  design  process  to  ensure  the  practicality 
of  proposed  designs  In  time-critical  mission  situations. 
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It  Is  a  truism  that  necessity  Is  often  the  mother  of  invention  ~ 
and  this  Is  certainly  true  with  regard  to  HOS.  It  was  conceived  out  of 
feelings  of  frustration  and  disappointments  with  the  impotency  of  human 
engineering  technology  of  the  mld-SIxties.  The  concept  of  a  Human  Operator 
Simulator  (HOS)  did  not  suddenly  appear  to  me  one  day,  but  was,  I  believe, 
the  Inevitable  outcome  of  consciously  searching  for  a  better  approach  to 
solving  human  engineering  problems.  The  concept  of  modeling  human  behavior 
had  attracted  me  for  a  number  of  years,  however,  prior  to  those  months  in 
1967  when  HOS  was  ultimately  conceived.  I  am  certain  that  the  prior  work 
with  which  I  had  been  Involved  in  the  area  of  vigilance  behavior,  informa¬ 
tion  processing  under  stressful  conditions,  and  predictions  of  student 
pilot  success  or  failure  were  Instrumental  In  directing  the  ultimate  con¬ 
ception  of  how  humans  processed  Information  and  did  various  tasks.  Factor 
analytic  studies  I  had  done  in  Pensacola,  Florida  on  a  rather  wide  variety 
of  pilot  tasks  had  left  on  me  an  Indelible  appreciation  (or  belief,  at  any 
rate)  that,  perhaps,  only  a  few  Independent  factors  really  accounted  for 
goodness  of  performance  In  what,  at  first,  had  appeared  to  be  very  diverse 
tasks.  Finally,  the  experience  which  I  had  gained  since  1959  in  programming 
computers  for  complex  applications  In  aviation  psychology,  medicine,  and 
biophysics  had  made  a  believer  of  me  with  regard  to  the  potential  power 
of  computer  simulation  for  solving  all  sorts  of  problems. 


Thus,  HOS  not  only  developed  from  a  specific  need,. but  It  also 
grew  out  of  what  I  consider  to  be  an  unusual  and  fortuitous  series  of  experl* 
ences  to  which  I  had  been  exposed.  To  better  appreciate  the  specific  purposes 
for  which  HOS  was  Initially  conceived  and  developed,  I  must  take  you  back 
to  late  1966  When  I  was  transferred  from  Pensacola,  Florida. to  the  Naval 
Missile  Center  (NMC)  at  Point  Mugu,  California  to  head  up  the  human  engineer* 
Ing  branch.  Our  mission  there  was  to  accomplish  the  tests  and  evaluations 
of  new  Naval  airborne  weapons  systems. 

To  perform  a  test  and  evaluation  one  must,  of  course,  first 
decide  what  one  desires  to  test.  It  became  obvious  that  two  different 
approaches  were  possible.  The  first  I  shall  refer  to  as  “comparison  with 
specs  and  standards"  and  the  second  I  shall  call  “performance  evaluation." 

The  first  approach  dealt  with  testing  whether  various  aircraft  displays, 
controls,  labels,  panels,  etc.,  conformed  to  Human  Engineering  guides, 
standards  and  specifications.  It  may  be  recalled  that  MIL  STO  1472 
and  MIL  SPEC  46855  were  first  Issued  in  1966.  8ecause  of  this  we  had  in  our 
possession,  at  that  time,  the  latest  documents  containing  data  on  what  the 
Navy  (and  the  other  services  as  well)  deemed  to  be  “acceptable"  HE  design 
standards.  On  the  other  hand,  because  of  the  newness  of  those  documents, 
no  system  arriving  for  test  and  evaluation  at  NMC  for  several  years  there* 
after  would  have  required  a  contractor  to  meet  those  standards  and  specifica¬ 
tions.  Thus,  those  documents  did  offer  a  standard  of  comparison  by  which 
at  least  some  aspects  of  the  crewstatlons  could  be  evaluated  even  though 
It  aright  be  difficult  or  Impossible  to  force  an  air  frame  contractor 
comply  with  those  standards.  A  second  drawback  In  using  MIL  STO  1472  was 
that  no  guidance  on  the  impact  on  operator  or  system  performance  was  pro* 
vlded  In  cases  where  various  aspects  of  crewstatlon  design  failed  to  meet 
the  new  standards.  I  found  that  It  was  virtually  Impossible  to  get  the 
Navy  Interested  In  correcting  any  single  deficiency,  because  no  single 
deficiency  was  ever  so  bad  as  to  be  able  to  say  that  it  alone  made  the  air¬ 
craft  either  unsafe  or  that  It  alone  would  be  the  cause  of  unsuccessful  or 
aborted  mission  performance.  It  was  obvious  to  our  human  engineering  team 
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that  the  cumulative  effect  of  a  series  of  minor  deficiencies  could  and  would 
have  a  major  impact  on  system  safety  end  mission  success.  To  be  able  to 
convince  others  of  this  point  of  view,  however,  would  require  a  fairly 
detailed  model  of  the  impact  of  various  display  and  control  features  on*- 
human  Information  absorption,  processing,  and  transmission  In  a  task  sequenc¬ 
ing  framework  to  Illustrate  such  cumulative  effects!  Unfortunately,  such 
models  were  not  available  at  that  time. 

The  second  approach  to  the  test  and  evaluation  of  the  crewstation 
dealt  with  attempting  to  determine  (regardless  of  conformance  or  non-con¬ 
formance  to  various  MIL  STDs)  If  the  operators  were  able  to  adequately  per¬ 
form  the  various  functions  which  had  been  allocated  to  them.  In  attempting 
to  determine  precisely  what  was  expected  of  a  given  operator,  we  had  occa¬ 
sion  to  examine  a  wide  variety  of  task  analyses  and  timelines  which  had  been 
prepared  by  a  variety  of  different  contractors.  Without  exception,  these 
rather  costly  Items,  when  they  had,  in  fact,  been  prepared,  were  extremely 
disappointing  In  terms  of  adequately  expressing  what  was  actually  expected 
of  a  given  operator.  All  too  often  task  analysis  blocks  had  been  prepared 
at  a  very  macro  level  (e.g.»  "Pilot  acquires  and  locks  on  target")  and  times 
assigned  to  such  activities  were, obviously,  merely  "educated  guesses."  It 
was  my  personal  experience  that,  at  least  by  the  time  a  weapon  system  was 
delivered  to  NMC,  no  task  analysis  or  timeline  indicated  that  the  operator 
would  be  too  busy  to  perform  all  the  functions  he  had  been  assigned.  The 
task  analyses  which  we  reviewed  In  those  days  also  failed  to  give  the 
reader  a  good  appreciation  of  the  often  necessary  simultaneity  of  various 
different  task  demands  facing  a  particular  operator  during  crucial  segments 
of  a  mission.  It  became  obvious  that  a  more  stringent  set  of  rules  were 
needed  In  guiding  whoever  prepared  task  analyses  so  that  (a)  an  appropriate 
level  of  detail  would  be  Included,  and  (b)  a  given  statement  made  by  a  task 
analyst  could  be  Interpreted  without  ambiguity  as  to  what  the  operator's 
responsibilities  were.  (From  this  concept,  the  Human  Operator  Procedures 
(HOPRCC)  language  ultimately  arose.)  Further,  It  was  felt  that  a  successful 
accomplishment  of  any  task  analysis  really  Involved  two  distinct  efforts. 
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the  first  of  which  was  expressing  what  was  expected  of  the  operator  (In 
terms  of  what  actions  he  must  take)  and  the  second  was  (given  the  displays, 
controls,  and  layout  of  the  crewstatlon)  to  determine  If  the  operator  cguld. 

In  fact,  accomplish  all  those  assigned  tasks  within  the  requisite  time. 

This  Implied  that  the  tasks  themselves  ought  to  be  able  to  be  described  * 
Independently  of  the  particular  crewstatlon  layout,  and ,  if  a  oopkLat&ostod 
human  parfoxmanea  modal  war*  aoailabls ,  then  the  Impact  of  different  crew¬ 
statlon  designs  could  be  reliably  and  objectively  evaluated  without  relying 
on  "educated  guesses”  by  contractor  personnel  who  had  a  personal  Interest 
In  making  their  own  aircraft  appear  to  be  good  In  the  Navy's  eyes. 

In  a  very  real  sense,  the  first  concept  of  HOS  was  never  Intended 
to  simulate  all  types  of  human  performance,  but  It  did  set  out  to  quantify 
performance  times  of  various  types  of  anatomy  movement  (head  and  eyes,  hands 
and  arms,  feet,  etc.)  and  the  effect  of  various  features  of  displays  and 
controls  (e.g.,  size,  contrast,  shape,  etc.).  Actually,  my  own  feeling  by 
late  1967,  was  that  we  were  a  long  way  from  being  able  to  predict  the  times 
various  mediated  mental  processes  might  take,  but  that  at  least  those 
observable  events,  such  as  anatomy  movements,  absorption  of  Information  frrm 
displays,  and  manipulation  of  controls,  should  be  able  to  be  accurately 
predicted.  In  this  respect,  I  was  especially  encouraged  by  the  work  of 
Topmlller  and  Sharp  (1965)  which  had  Indicated  that  arm-hand  reach  time  was 
very  predictable.  Also  several  Informal  studies  (whldi  I  deeply  regret,have 
never  been  published)  on  eye  movement  and  fixation  times  and  on  numeral  and 
dial  reading  times  which  were  conducted  by  Alvah  Bittner  and  myself  at  Pt.  Mugu 
that  greatly  supported  the  concept  that  any  task  could  be  broken  down  Into 
sequences  of  various  micro-  processes  and  the  sum  of  the  micro  process  tiies- 
would.  In  fact,  yield  the  total  task  times.  Many  people  rejected  such  a 
hypothesis  and  predicted  that  there  would  be  tremendous  Interactions  among 
many  If  not  all  of  the  micro  processes  which  would  make  the  analytical 
"additive”  approach  I  was  advocating  doomed  to  failure.  Such  discussions 
and  arguments,  I  might  add,  were  very  philosophical,  since  neither  I  nor 
my  opponents  had  sufficient  data  to  support  our  contentions  In  those  days. 
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I  suppose  I  stuck  with  the  belief  that  each  micro  process  was  Independent 
primarily  because.  If  it  turned  out  not  to  be  true,  there  would  be  little 
hope  for  a  " scientific "  approach  to  human  engineering  In  the,  then,  fore¬ 
seeable  future. 

In  addition  to  the  above-mentioned  reasons  for  the  development  of 
a  HOS,  there  was  yet  another  reason.  In  those  days,  we  were  conducting  some 
open-loop  simulations  of  various  missile  and  missile  launch  systems.  In 
one  conducted  by  Chuck  Hutchins,  It  was  discovered  that  operators  in  the 
laboratory  simulation  were  getting  very  good  scores  on  locking  onto  and 
launching  a  simulated  missile  at  a  simulated  target.  It  was  also  discovered 
that  the  operators  were  waiting  until  minimum  range  to  launch  their  simulated 
weapons.  The  simulated  targets  were  capable  of  maneuvering,  but  the 
maneuvers  were  "canned"  and  had  nothing  to  do  with  the  maneuvering  our 
pilots  were  doing.  Further,  the  simulated  targets  never  fired  back,  which 
might  well  account  for  the  willingness  of  our  pilots  to  wait  until  minimum 
range  to  release  their  missiles.  Thus,  the  concept  of  a  simulated  human 
operator  to  be  used  as  an  Intelligent  adversary  was  also  one  of  the  original 
planned  uses  of  a  HOS  (although,  to  date,  HOS  has  never  been  used  for  this 
purpose). 

In  formulating  the  philosophy  of  how  one  could  simulate  a  human 
operator's  behavior,  one  major  concern  I  had  in  1967  was  whether  a  human 
being  could  be  considered  to  be  a  discrete  or  continous  information  processor 
In  those  days,  many  people  held  to  the  concept  that  man  was  indeed  a  con¬ 
tinuous  processor.  If  this  were  true.  It  might  be  more  appropriate  to  use 
an  analog  rather  than  a  digital  computer.  However,  by  reanalyzing  some  data 
collected  much  earlier  by  John  Senders,  I  came  to  the  conclusion  that  even 
In  a  continuous  tracking  task,  the  human  appeared  to  be  sampling  the  avail¬ 
able  displayed  Information  only  about  13  times  per  second.  Thus,  man 
appeared,  at  least  to  me,  not  to  be  a  continuous  sampler,  but  a  discrete 
one  who  could  relatively  easily  be  simulated  with  a  digital  computer. 


Another  major  philosophical  point  was  whether  man  should  be  con¬ 
sidered  to  be  a  single-  or  multi -channel  processor.  This  Is  more  than  a 
question  of  whether  an  operator  can  be  responsible  for  carrying  out  more  than 
one  task  at  a  time,  for  this  he  might  appear  to  do  even  if  he  were  a  single¬ 
channel  operator  capable  of  very  rapid  Interlacing  among  more  than  one  task. 
The  single-channel  vs.  multi-channel  question  really  Involves  on  the  issue 
of  whether  the  operator  can  aimultcoiaoualy  be  thinking  about  two  different 
things.  After  much  Introspection  (as  well  as  considering  the  writings  of 
various  experts  on  this  question),  I  chose  essentially  to  conceive  of  man 
as  being  a  single-channel  processor  who  Is  capable  of  rapidly  multiplexing 
among  several  tasks. 

This,  in  turn,  led  to  the  concept  In  HOS  of  permitting  the  simulated 
operator  to  have  many  different  procedures  going  on  at  the  same  time.  In 
HOS,  we  call  these  the  aotiva  procedures,  while  those  which  are  not  currently 
of  concern  to  the  operator  are  known  as  inaotivs  ones.  However,  while  many 
tasks  may  be  active,  HOS  only  works  on  one  at  a  time. 

One  of  the  earliest  studies  I  did  (long  before  HOS  or  the  HOPROC 
language  existed)  was  a  relatively  simple  computer  simulation  to  determine 
what  would  happen  under  various  strategy  algorithms  for  deciding  which  dis¬ 
plays  to  pay  attention  to  when  the  simulated  operator  was  responsible  for 
monitoring  several  different  ones  at  the  same  time.  These  early  studies  led 
to  the  concepts  of  a  monitoring  proesdurs  for  a  display  as  well  as  the  concepts 
of  a  procedure's  aritiodlity  and  the  Idea  that  criticality  could  dynamic¬ 
ally  change  as  a  function  of  the  disparity  between  a  display's  daairad 
voaition.  Its  allcMibla  limits,  and  Its  aatimatad  position.  These  concepts 
have  been  retained  In  HOS  since  Its  beginning  stages  back  In  early  1968. 

Such  algorithms  provide  the  basis  for  the  adaptiveness  of  the  behavior 
exhibited  by  HOS. 


Another  very  early  consideration  (which  has  changed  very  little 
over  the  years)  was  how  to  handle  "short-term"  memory  of  the  simulated 
operator.  The  concept  of  hab  strength  (which  is  discussed  elsewhere) 
and  the  probability  of  successful  recall  of  an  item  of  information  which- 
had  been  recently  absorbed  was  a  concept  which  I  adapted  from  Hull's  and 
Thorndike's  theories  of  learning.  The  concept  of  modeling  short-term  memory 
was  felt  to  be  necessary  to  determine  how  often  the  human  would  feel  a 
necessity  to  update  his  current  information  about  some  parameter  by  actually 
looking  at  a  display. 

By  1968,  the  basic  concepts  of  HOS  which  Included  micro-process 
handlers,  adaptiveness  algorithms,  short-term  memory,  with  the  operator  as 
a  single-channel  processor  capable  of  rapid  multiplexing  among  the  "active’ 
procedures  had  been  formulated  In  detail  as  well  as  the  earliest  version 
of  the  HOPROC  language  by  which  the  user  would  specify  what  it  was  that  the 
simulated  operator  was  expected  to  do.  These  concepts  were  reported  in  the 
proceedings  of  a  two-day  meeting  jointly  hosted  by  the  Office  of  Naval 
Research  and  North  American  Aviation  in  Columbus,  Ohio  in  November,  1968. 

It  is  surprising  and  somewhat  rewarding  to  see  how  little  the  basic  concepts 
formulated  10  years  ago  have  changed  during  its  development.  It  is  also 
Interesting  to  note  that  I  and  other  participants  at  that  meeting  estimated 
that  it  might  take  10  years  to  develop  HOS. 

By  1969,  I  was  able  to  get  some  Independent  Research  (6.1)  funds 
to  pay  for  a  programmer  (Hr.  Don  Kennerly  —  then  a  member  of  our  HE  branch) 
to  start  programming  both  the  earliest  versions  of  HOS  and  HAL  (the  HOPROC 
Assembler/Loader  program  which  was  to  decipher  the  HOPROC  statements  for 
input  to  the  HOS  program).  These  earliest  programs  did  not  include  all  the 
specifications  of  HOS  mentioned  above  and  HAL  was  written  in  COBOL.  More  than 
anything  else,  they  proved,  at  least  to  my  own  satisfaction,  that  it  would 
be  feasible  to  write  a  digital  computer  program  for  a  full-blown  HOS.  It 
was  also  In  1969  that  Bittner  and  I  did  the  experiments  mentioned  above  which 
also  were  very  encouraging  regarding  the  concept  of  the  additivity  of  micro¬ 
process  times. 


In  August  of  1970,  I  was  transferred  to  the  Naval  Air  Development 
Center  In  Warminster,  Pennsylvania  and  It  was  Imnedlately  obvious  that  a  HOS 
would  be  even  more  valuable  during  early  system  development  than  during 
later  test  and  evaluation  phases  of  system  design. 

Paul  Chateller,  who  was  at  that  time  stationed  at  NADC,  was  In 
the  throes  of  formulating  CAFES  which  also  dealt  with  computerized 
approaches  to  Improving  human  factors  engineering  technology.  (Later  fund¬ 
ing  for  HOS  was  formally  Included  In  the  CAFES  program  element  number,  but 
for  two  years  they  stayed  as  separate  development  efforts.) 

By  December  1970,  Analytics  became  Interested  In  the  HOS  concept 
and  submitted  a  proposal  to  work  on  Its  further  development.  Prior  to 
that,  I  had  discovered  that  although  I  had  brought  the  HOS  and  HAL  programs 
(written  by  Kennerly)  with  me,  NADC  did  not  have  a  version  of  COBOL  which 
could  compile  the  HAL  program  as  It  then  existed.  It  was  decided  that  It  would 
be  better  to  have  all  the  future  programs  written  In  FORTRAN  for  subsequent 
ease  In  transferring  them  about  the  country.  The  first  contract  to  Analytics 
for  work  on  HOS  was  let  In  1971  and  out  of  that  effort  what  I  might  call  HOS 
II  and  HAL  II  were  developed. 

As  more  work  was  accomplished  on  HOS,  It  became  obvious  that 
various  additional  statements  In  the  HOPROC  language  would  be  desirable  as 
well  as  a  greater  flexibility  In  how  one  could  express  various  statements. 

For  a  while,  these  additions  were  added  as  patches  to  the  program  until  It 
became  obvious  that  It  was  time  to  go  back  and  Incorporate  all  these  changes 
as  well  as  some  additional  new  concepts  Into  the  HAL  and  HOS  programs.  Thus, 
what  had  been  available  since  late  1975  actually  Is  what  we  might  call  HOS  III 
and  HAL  III.  Since  that  time,  we  have  almost  exclusively  been  Involved  In 
validity  testing  of  HOS  III  and  little  or  no  additional  development  has  taken 
place. 


This  does  not  mean  to  Imply  that  HOS  is  considered  to  be  In  its 
final  or  ultimate  stage  of  development,  for  there  are  many  additional  features 
which  should  and  could  be  added  to  HOS.  However,  HOS  III  does  represent 
what  I  consider  to  be  a  highly  useful  technique  for  the  initial  assessment 
of  how  well  a  trained  operator  will  be  able  to  perform  his  tasks  In  a 
specified  crewstatlon  under  varying  situational  demands. 

One  concept  which  was  definitely  added  to  HOS  in  1974  which  was 
a  rather  marked  departure  from  original  plans  for  HOS,  was  the  concept  of 
simulating  the  system  hardware  and  software  as  well  as  targets  using  the 
HOPROC  language  and  the  HAL  and  HOS  programs.  Originally,  HOS  was  only  to 
be  the  Human  Operator  Simulator  and  it  was  anticipated  that  it  would  be 
Interfaced  to  hardware  simulators  in  some  fashion.  It  was  found,  however, 
that  It  would  be  extremely  difficult  to  modify  hardware  simulators  written 
by  others  so  that  HOS  could  easily  interface  with  them.  After  much  soul 
searching,  it  was  decided  to  expand  the  HOPROC  language,  HAL  and  HOS,  to 
include  the  ability  to  simulate  hardware  as  well  as  the  human  components. 

These  changes  were  also  Incorporated  and  indeed  necessitated  the  rewriting 
for  HOS  III  and  HAL  III. 

The  concept  of  a  HOOAC  (Human  Operator  Data  Analyzer/Collator) 
program  to  analyze  the  human  operator  data  emminatlng  from  a  HOS  run  was 
Included  In  the  very  early  stages  of  HOS  planning.  The  first  HOOAC,  how¬ 
ever,  was  not  available  until  1974.  It  has  proven  to  be  less  useful  than 
I  originally  thought  It  might,  but  this  may  be  due,  in  part,  to  the  fact 
that  we  have  to  date  been  most  interested  In  seeing  if  HOS  behaves  like 
real  operators  In  systems  which  have  already  actually  been  built  (l.e.,  our  . 
validating  studies)  rather  than  In  systems  which  are  actually  under  develoo- 
ment.  It  may  be  that  many  of  the  routines  available  in  HOOAC  will  turn 
out  to  be  very  useful  In  deciding  potential  changes  to  procedures  and  crew- 
station  design  when  we  try  HOS  on  a  developing  system  and  we  determine  that 
unless  something  Is  changed.  It  will  be  Impossible  for  the  operator  to  success¬ 
fully  do  all  his  allocated  functions. 
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While  HAL  III  and  HOS  III  both  now  contain  the  additional  capa¬ 
bility  for  simulating  hardware  and  target  systems,  there  Is  no  automatic 
logging  of  their  behavior  as  there  Is  with  the  simulated  human  behavior. 

In  part,  this  Is  due  to  the  fact  that  HOS  does  not  contain  a  general  pur¬ 
pose  hardware  system  model  which  Is  made  system  specific  by  the  hardware 
procedures  and  hardware  functions.  Lacking  an  overall  scheme  for  a  general 
hardware  system  means  that  hardware  systems  are  not  automatically  reducible 
to  a  specified  number  of  micro-processors  which  can  then  be  automatically 
logged  out  whenever  they  are  used.  This  necessitates  some  amount  of  clever¬ 
ness  on  the  part  of  the  HOS  user  to  either  log  out  and/or  accumulate  data 
of  Interest  ot  overall  system  performance. 

Earlier,  I  mentioned  that  HOS  should  not  be  considered  to  be  fully 
developed.  Areas  where  HOS  might  be  expanded  to  include  the  addition  of  a 
fatigue  modes,  the  capability  to  pick  up  and  move  objects  from  one  place  to 
another,  the  capability  to  walk  (or  run)  from  one  place  to  another,  the  ability 
to  talk  to  another  operator,  the  capability  to  perform  visual  target  recogni¬ 
tion  in  a  complex  visual  field,  etc.  I  am  convinced  that  each  of  the  above 
concepts  can  be  added  to  HOS  and  I  have,  at  least,  rudimentary  models  or 
schemes  for  handling  all  of  the  above  concepts  as  well  as  several  others. 

With  the  rather  successful  validation  studies  which  have  been  conducted  on 
HOS  III,  it  Is  probably  now  time  to  start  the  development  of  HOS  IV  and  HOS  V 
which  would  be  versions  to  Include  one  or  more  of  the  above  concepts. 

Finally,  I  would  be  remiss  If  I  did  not  discuss  the  concept  of 
operator  error  as  it  is  treated  In  HOS.  More  than  any  other  single  Item, 
the  way  operator  error  Is  treated  in  HOS  has  been  criticized.  With  a 
few  exceptions  (which  are  discussed  elsewhere),  HOS  does  not  make  errors. 
Some  people  claim  that  this  Is  unrealistic,  but  1  maintain  that  as  long  as 
the  human  operator  Is  given  the  requisite  amount  of  time  to  do  a  task,  then 
he  does  not  make  errors.  He  may  not  finish  all  the  tasks  we  would  like 
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him  to  do*  and  he  may  not  do  them  as  well  as  we  would  like  him  to  do  them* 
but  as  long  as  he  works  at  a  reasonable  pace*  he  will  not  make  an  error. 
The  fact  that  he  doesn't  get  all  his  tasks  accomplished  when  he  works  at 
a  reasonable  pace  merely  Indicates  that  we  allocated  too  many  tasks  to 
him.  Thus*  If  HOS  Indicates  the  simulated  operator  spends  too  little 
time  on  a  given  task,  we  may  either  assign  a  higher  criticality  to  that 
task  and  rerun  the  simulation  to  see  if  this  alleviates  the  problem,  or 
we  may  reduce  the  number  of  tasks  which  were  originally  allocated  to  the 
operator  to  see  if  this  solves  the  problem. 

I  am  certain  that  real  systems  do  exist  in  which  operators  make 
mistakes.  On  the  other  hand*  this  is  a  clear  indication  that  we  have. 

In  those  systems,  asked  the  operator  to  do  too  many  and/or  too  complicated 
tasks  and  therefore  those  systems  are  not  properly  human  engineered  by 
definition,  since  successful  performance  of  the  tasks  are  not  within  the 
capabilities  of  the  operator.  What  HOS  does  is  essentially  to  "instruct” 
the  operator  not  to  attempt  to  work  at  a  pace  at  which  errors  and  mistakes 
will  occur  because  we  hold  to  the  concept  that  errors  acre  the  result  of 
being  under  time  stress  and  that  error-free  performance  can  be  maintained 
provided  the  operator  does  not  attempt  to  do  too  many  things  in  too  short 
of  a  time  period.  The  human  errors  that  are  observed  in  existing  systems 
are  the  result  of  real  operators  attempting,  unsuccessfully,  to  perform 
at  a  higher  level  than  their  capabilities  permit. 


In  closing  this  brief  historical  perspective,  I  should  also 
mention  that  working  on  the  development  of  HOS  has  been  both  fun  and 
exciting.  The  associations  I  have  formed  with  the  many  people  who  have  parti¬ 
cipated  In  this  development  program  has  been  very  rewarding  professionally 
over  the  years.  Finally,  working  on  HOS  has  also  often  been  a  humbling 
proposition  as  we  have  discovered  how  little  we  actually  know  about  how 
humans  behave. 
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